• Advertisement
Sign in to follow this  

Getting started, few questions

This topic is 3234 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So ive read several few articles, checked the msdn docs, etc and managed to get a client-server thing working where the client can send messages that the server displays in the console window. However some things are still unclear to me. Right now I'm just using tcp with winsock2.2 -I dont need to worry about the packets actaully being sent. send() just queues up my data till it has a complete packet behind the scenes -Assuming the above is correct, is there some sort of flush() method that tells it to stop waiting (eg because there nothing more coming for a while) and just send what it has? -If send or recv fail, trying again probebly wont help anything, since they shouldnt normally fail (ie if packets are dropped,, corrupted, etc winsock handles it completetly transparently)? -Its garunteed that the data i'm getting from recv is the same data that I sent, ie any corruped packets are handeled for me? -If one end of a connection crashes (so doesnt call the closesocket, etc), recv will still return 0 for disconnected at the other end (it seems to, but I'm not sure if this is garunteed)?

Share this post


Link to post
Share on other sites
Advertisement
As for the corrupted packages, TCP is a reliable stream delivery service, which means that it handles resending packages until it gets an acknowledgment from the receiver that the packet was sent. IIRC, TCP also guarantees that the packages arrive in the order they were sent.

Share this post


Link to post
Share on other sites
I checked the MSDN documentation for recv regarding your last question. It says "If the connection has been gracefully closed, the return value is zero."

http://msdn.microsoft.com/en-us/library/ms740121(VS.85).aspx

However, in my experience, recv also returns zero if the connection is abruptly closed, i.e. not very gracefully. My test clients are usually Symbian-handheld devices where the battery might run out, for example.

Share this post


Link to post
Share on other sites
usually the connection will time out if you crash. But you may get a "conn reset", or other error signalling you the other end of the connection is in trouble.

You have to remember that when you send data, the data is buffered first. If the buffer gets full (you want to append more to the buffer than the connection can send), the send function will either block, or return a "wouldblock" error, that you can act upon, and resend. If you want to send a large file across, that would be the case.

You can set the buffer size as part of the socket option. Typically, it is 16 Kbytes, and up to 64 Kbytes, but depending on the protocol, OS, and what's suppported, that can change (you could have buffers Megabytes in size).

So, act on the return value of the send() function, to decide what needs to be resent (I'm not sure is send() would return a 'partial' amount of bytes, or just return an error).

For recv, "wouldblock" would also be returned if no fresh data has been received. That is if you use a non-blocking socket.

For the flush(), that is also a socket option, I can't remember exactly what needs to be done, but that's not a huge hurdle.

TCP is a stream, so the data you send could be fragmented, but it will be in order, accurate, with variable latency. Say you send 100 bytes in one call. On the other end, you may receive first 10 bytes, then 20 bytes, then the final 70 bytes, in three recv() calls. You need to create your own protocol (packet headers) to re-construct the messages with the appropriate size.

It is possible the data you receive is corrupted, but the chances of that are minute. TCP performs a checksum on the data packets, to guarantee almost 100% reliability, but no checksum is 100% reliable.

Share this post


Link to post
Share on other sites
Flushing data happens automatically within a few hundred milliseconds, so you don't need to worry about it much. If you are doing interactive things, then you should use TCP_NODELAY, which means that each send() will be considered for immediate transmittal. Linux also has TCP_CORK, but WinSock does not.

Yes, corrupted packets are handled for you (using a moderately strong CRC, plus whatever the underlying transport provides). Also, send() and recv() will not suddenly succeed after previously failing. However, recv() may return less data than you sent in send(), with more data coming in the next call to recv() -- this is not failure; it's just a property of TCP being a stream.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement