I am working on TCP client server application using c++.third party lib are now allowed in this project.
Here exchange between client server takes using well define protocol format.once the client receives the packet it will send it for parsing.I have protocol manager which will take care of the parsing activity.
I have following doubt
When the data arrives at client from the network,
the OS buffers it until application calls recv() function.
So two message msg1 and msg2 arrives at the buffer a call to recv will return msg1+msg2.
Now this may result in failure of the parsing activity.
My queries
1. whether above mentioned assumption is correct or not ?
2. If above mentioned assuption is correct then how can resolve this issue.
TCP emulates a stream, so in TCP there is no notion of messages. If you want messages, your application has to have some protocol to seperate them.
UDP does have a messages, so there it is possible to retrieve separate messages.
You can use a LV protocol (Length-Value) for your message.
Encode the message length in the first (1-4) bytes, then put the message.
Something like this for example : 14"Hello world\0"
In your server, when a client is sending something you'll have to recv() the first (1-4) bytes then recv() the length of the message.
Related
I am using a POSIX OS (vxWorks) and want to understand how to process TCP data. I understand in UDP everything is really up to you and TCP is a lot more managed underneath.
Suppose a remote socket I am connected to promises to send me JSON data. The documentation simply says, once established, we will send you JSON data.
Using the function recv on the TCP socket, and assuming I give it a buffer of an extreme size, should I expect that I would always get perfectly assembled JSON data even though the message may be sent in multiple chunks on the interface layer, or do I need to essentially parse each buffer of data I received until I think I have a fully formed JSON message?
TCP has no idea about application messages. You need to implement the protocol layered on top of TCP to find message boundaries, if your protocol has one.
In our client/server application, we use TLS/TCP protocol for messaging. There is a message shift occurs between applications after a while (messages are sent and received in the correct order at the beginning) i.e. the client sends the 1000th message to the server and receives the response of message 999th. The suspect is on the client side, in which we implement TCP and TLS layers independently i.e. do not bind TCP socket to SSL object (via SSL_set_fd()) but using BIOs. When the client app gets the response from server (pretty sure that message is processed in the server correctly, client TCP layer receives the message correctly etc.), the message is forwarded to SSL layer. The client app firstly write the message to BIO:
BIO_write (readBio, data, length);
Then in another function of SSL layer, the message is read using SSL_read():
res = SSL_read (ssl, buffer, length);
The read operation is done successfully, but my goal is to check whether there is another record(s) to be read in the BIO. I considered to use the method SSL_pending() but it seems that this one should be used in order to check if there are still bytes in the SAME record. If our suspects are correct, I would like to check if there is another record in the BIO so that all messages are processed without any delay. Can you help me on this topic? Thanks in advance.
SSL_pending tells you if there are data from the current decryted SSL record which got not yet read by SSL_read. BIO_pending can be used to find out if there are already data in the BIO which are not processed by the SSL layer. To find out if the are unread data at the socket level use MSG_PEEK.
Consider the following scenario:
I have a server and a client, and they communicate in a custom defined application protocol.
A typical conversation is like this: (Assuming a connection between the two)
Client sends message to server, and waits for acknowledgment (don't
confuse with TCP) that it's message has been processed
Server parses the message and as soon as it reached the end it sends
an acknowledgment back to the client that it has processed it's
message
Client gets the acknowledgment and can now freely send another
message and wait again for an acknowledgment etc etc.
I have come to a problem implementing this. I am looping recv() parsing the message but as soon as recv has nothing more to return it blocks, and my code can't proceed to argue that I've received the whole message so that it sends an acknowledgment.
I've managed to somehow come around this by sending a message size in the header of the message and counting each time whether I've read as many bytes as the message size, but this is not ideal; what if the client machine bugged and it sent an incorrect size?
Also, I've read in another question that this whole acknowledgment process I'm doing is not necessary when using tcp, and that tcp already does that for you; but isn't the handshake only done once per connection? What if I don't close the connection between the two? Then only one handshake at the creation of the connection would have happened.
Do I have to create a new connection every time I want to be sending something? And isn't the handshake done before the data is sent, and only when making the connection? So this might not be what I'm looking for in my case.
I'm new in network programming and I'm trying to understand how functions like send and recv work under the hood in a TCP connection.I know that in a connection between a client and a server for example ,when the client manage to send a message to the server ,the message is split in different packages and at it's arrival,the server part checks to see if the sum of the packages is the same as it was before sending,and if is ok it sends a message back to the client as an approval.If a problem appears the client resends the message.
What I don't understand is that if you send a message from the client and you sleep the server for 10 seconds,you can still do what you want in the client,like the send function is executing in another thread ,or if you use multiple times send function in these 10 seconds,the message arrives as a combination of the messages used in that time.
If anyone can explain the situation ,I'll be very grateful !
This is implemented by the TCP/IP networking stack of your operating system.
The TCP/IP stack ...
provides a send buffer. When your program sends, the OS first fills internal buffers. You app can send immediately until the buffers are full. Then your send will block.
takes data from the internal buffer and sends it out onto the network in single packets.
receives data over the network and fills internal receive buffers with that data.
gives your program the data from the internal buffers when you call receive.
takes care of the TCP/IP protocol stuff like establishing connections, acknowledging received data, resending data if no receive acknowledge was received.
In the case you wrote the client is filling the sender OS's send buffer and the receiver OS's receive buffer. Your client can send non-blocking until both buffers are full. Then it will block until the server calls recv again.
I have 2 UDP sockets (SOCKET), one for sending and one for receiving on a Windows machine. They both work well, but the trouble is that a program that is receiving messages from my send socket replies to the same port which sent the message.
I know that if I don't bind the send socket, using sendto will pick an ephemeral port to send on.
I'd like to know if it is possible to any of the following, and if so, what is the recommended way to do it:
Bind both the send and receive sockets to a chosen port so that when the external program sends a message back it can be received.
Update the port to which the receive socket is bound in such a way as to receive on the port from which I last sent a message (not sure if this would create a race condition).
Some other correct method.
So far I have tried:
Not binding the send socket (it sends from some open port to the destination port). I can successfully receive messages on that port for as long as it doesn't change, but eventually it does change.
Binding both the send and receive sockets to a desired port. This creates the desired behaviour when I watch the packets using a sniffer, but the receive socket never receives the messages even though I see them being transmitted to the correct port and IP.
Packets are being received from more than one outside entity, and not guaranteed to be in any particular order.
Thank you in advance!
Looks like you are trying to use threads to separate sending and receiving data. I would question this approach, since UDP is so easy to handle in one thread. Nevertheless, you can just use the same socket from both threads if you want (see related question: Are parallel calls to send/recv on the same socket valid?). Just bind(2) it and, optionally, connect(2) it.