Forgive me for the following, as my understanding of winsock is not quite yet complete (I have only started looking in to it over the past two days). For now, my question is brief and more of a "can I do this the way I want to do it?" ordeal. On to the inquiry itself:
A member of my lab has written a nice winsock server that communicates with a client to transmit instructions to various instruments connected via serial. That part is already written and thankfully I do not have to touch; it works universally for all serial devices. However, the existing clients are all written in MatLab, and I'm trying to rewrite them in C/C++.
I've managed to successfully connect to the server and establish a socket. I can receive the data it sends and display it on the client. Great!
The problem I'm having thus far - after all of the initial data (containing instructions) is sent to the client, I cannot do anything. It will display the received data as text, but does not break the simple do while loop I have and ask the user for an input to transmit.
I'm wondering if it possible to set up a receive-then-transmit loop between the server and the client, such that I can send a command and receive the response with one socket in the client until I am done with talking to the server?
I will post my code tomorrow morning once I'm back at my lab computer!
Thank you for your time.
Related
I have read a lot of articles and questions about socket programming but I don't get one thing.
Imagine I have some wi-fi network, and some device connected to that wi-fi network. I send some message to the device over the wifi network, the device get's it (sure thing) and sends something to a server and I want to read (receive) that message and send it somewhere else, or even just std::cout it. How should I connect, and receive it because I don't really know how.
To better explain it:
A - device connected to wifi (device has got some IP address)
B - app that sends message to A
C - server that listens and receives messages
that device A sends
And my question is, if B connects to A and sends something that A got, how should C get that what A give's away.
To answer this part of the question "How should I connect, and receive it because I don't really know how?"...
Take a look at boost::asio and boost::beast. Lots of functionality here. Should be able to do whatever you want with the socket and talking to other devices over the network.
To answer the second part of the question...
"
A - device connected to wifi (device has got some IP address)
B - app that sends message to A
C - server that listens and receives messages that device A sends
And my question is, if B connects to A and sends something that A got, how should C get that what A give's away."
I'm a little confused as to what you mean here.
If C is the intermediary, that's easy. C receives whatever packets contain the message from B, reads, and then reroutes them (or duplicates what is necessary and sends it to B).
Also, here's a good resource from Duke on how this all works.
How to do this without boost. More info on doing this without boost. Google is your friend :).
First questions here. I gave searched for this but haven't found any solution which fully answers my problem here. I'm using c++ and need to write a kind of usp chat (server and client) for programs to interact with one another. Well atm it works quite well.
I'm using Googles protobuf as Messages.
I've written it like that:
Server has a list of users curently logged in as well as a list of messages to process and distrubute.
One thread handles all receiving on its socket (I'm using one socket).
If command var in the message is login,
It looks through the list and checks for this combination of port and IP. If not in, the chat creates a new user entry.
If command logout, the server looks for the user in list and deletes it.
If command is message, the server looks if user is logged in and puts it on the message list.
The 2nd thread is for sending.
It waits till there is a message in the list and then cycles through all users to send this messages to their sockets except the sending one.
The server has set options on its socket to receive from any ip.
My question now is: is this the most performat solution?
I've read about select and poll. But it's always about multiple receiving sockets while I have only one.
I know the receiving thread may be idling all the time but in my environment there would be a high frequent message input.
I'm fairly new to socket programming but I think this was the most elegant solution. I was wondering if I could even create another thread which gets a list from receiving thread to process the messages.
Edit: how could I detect time outs?
I mean I could have a variable in the user list which increases or get set to 0. But what if messages won't come frequently. Maybe a server based ping message? Or maybe a flag on the message which get set to acknowledged and gets resend.
On the user side I need to first broadcast to find the server and then set port and up accordingly to the answer. How could I do that?
Because this should run autonomous. Meaning a client should detect dmthe server, login, sends its commands and detect wether it is still online.
On server side I don't know if this is so important. Possibly there might be a memory issue if there are too many things connected and non get logged off. Maybe I set a 1 h timeout to let it detect idle clients.
I am making an application where I have a client and a server. The client will send some coordinates to the server which will use those to move a robot. What I want is to synchronize the timers, used for time stamping log data, so that I can compare the input vs output. The communication is done through TCP/IP, and the client is done in C++ while the Server is in RAPID (ABB robotic programming language). My problem is that the timers are not synched properly.
Right Now the timers start when the connection between the two is established:
Server side:
ListenForConnection;
startTimer;
Client side:
connectToServer;
startTimer;
This does not work. Is there a technique to ensure that the timers are synchronized?
NB: The server can only be connected through LAN.
You need a protocol between client and server to pass the timestamp.
Right now, presumably you have a protocol for sending coordinates. You need to extend that somehow to allow one side to send timer information to the other side.
The easiest is if you have two way communication capability. In that case, the client does
Connect to server
Keep asking until the server is there
Server says "yes I'm here, the time is 1:00"
The client starts sending coords
If the server has no way to send to the client, then the client needs to send a timestamp from time to time, which the server recognises as being a time, not a coordinate. The two will not be synched until this happens the first time.
In my app i sent packet by raw socket to another computer than get packet back and write the return packet to another computer by raw socket.
My app is c++ application run on Ubuntu work with nfqueue.
I want to test sent packets for both computer1 and computer2 in order to check if they are as expected.
I need to write an automation test that check my program, this automation test need to listen to the eth load the sent packets and check if they are as expected (ip,ports, payload).
I am looking for a simple way (tool (with simple API), code) to do this.
I need a simple way to listen (automate) to the eth .
I preffer that the test will check the sender , but it might be difficult to find an api to listen the eth (i sent via raw socket) , so a suggested API that will check the receivers computers is also good.
The test application can be written in c++, java , python.
The only way to check if a packet has been sent correctly is by verifying it's integrity on the receiving end.
Auto generate a large list of random packets, give the list to both computers and start sending them and when received, have them checked against the list. Computer 1 will send and then wait for a reply from computer 2. Computer 2 will check the packets and then send either a success or failure packet. Log the results on either computer (doesn't matter) and then you could generate statistics from the log file. Use this method in both directions to test both connections if needed. Should be extremely simple in python.
Or go crazy and use Hamming Codes:
http://en.wikipedia.org/wiki/Hamming_code (wiki)
http://lionel.textmalaysia.com/hamming-code-in-python.html (explanation and some code)
I operate tcpdump on the reciver coputer and save all packet to file.
I analysis the tcpdump with python and check that packet send as expected in the test.
I currently have a basic chat program in c++ that uses WinSock2.h with UDP. Currently the user is able to send a message to the server and the server just sends the same message back. I was wondering where do I go from here (i'm not asking for code). I was wondering how I should go forward in having the messages get sent to another client that is also connected to the server.
If I need to explain what I have done already please let me know.
All suggestions are greatly appreciated.
Thanks
You would have a list of currently connected users, when a user sends a message, it would then post it to all connected users.
Your server would keep track of who is connected, and remove those who get disconnected. When someone connect or disconnects, it would send a notification to all currently connected users, telling them of this notification.
All this is not specific to UDP, infact, TCP would probably be better for this type of messaging as you do not have to worry about messages being dropped. UDP should only be used where performance is of upmost importance, like real-time gaming, voice chat.
When you're saying "connected" (in the context of clients) - what exactly do you mean?? Because you say you're using UDP in your program.
In the UDP protocol there's no "connected" state, unless you implement it.
In the TCP protocol however, there is (implemented within the protocol itself).
Furthermore, the basic idea of "broadcasting" a message is simple - keep a list of connected clients.
Add a client when it connects. Remove it from the list when it disconnects.
Then when you want to send a message to everyone you just iterate through this list.
Again, you'll have to receive those dis/connect events before you could keep track of "connected" clients.
If you go with TCP instead of UDP then you're set.
Good luck.
Basically, like Matthew said, you need to store all the current connections to the server. When a socket connects you can store a reference to that socket. Now whenever a client sends a message you can rebroadcast that to all the sockets. Now you have to handle when sockets disconnect as well since you don't want to store a bunch of closed sockets.