WSAEWOULDBLOCK forever

Thanks for the ideas :-)
Is there a way to call recv() without triggering an FD_READ event\message?? Or to find out how much data is on the socket before reading to make sure it's not empty?? I ask because the only way I can think of only calling recv() when I get an FD_READ message would be to keep a char buffer open and always read into that, then memcpy() the contents elsewhere when I need to, but that brings up lots of quite nasty little problems when I need to do things like adding file transfer too.

As for the other issues, I changed my switch statement and the client only has one socket, and only calls WSAAsyncSelect() on that one socket so I'm not sure how I'd be getting messages for another socket but I have added checks to make sure it only processes it's own socket :-) Thanks for that :-)

Gah, I meant that I replaced unsigned long data_chunk = data_size; with int data_waiting = recv( sock, data, data_size, MSG_PEEK ); otherwise I'd get the same WSAEWOULDBLOCK error if recv() ever returned -1 ;-)

Anyways, I'm still getting a loop somewhere if it manages to recv() enough bytes to build a header, but not enough to recv() the rest of the message. If msg is ever empty, it stalls.

Gotta keep working on it ;-)

Is there a neater method that I could employ??
No, that's the price that you pay for asynchronous notifications: you are required to implement a mini-state-machine that remembers your current place in the receipt of data, from one FD_READ event to the next.

A single dedicated thread does not have this requirement, since it receives notifications that are synchronous, which is apparently why you did not experience it in the development of the server.

Incidentally, MSG_PEEK is on the winsock lame list. Experienced network programmers always recommend to avoid its use. One reason is inefficiencies. Another is the fact that the winsock stack runs in its own threads, so that the information returned by MSG_PEEK might change between the time that you call it and the time that you use the returned result. See http://tangentsoft.net/wskfaq/articles/lame-list.html at items 12 and 16.

It is possible to disable FD_READs while recv()'ing. Before calling your first recv(), turn off asynchronous notifications with a call to WSAAsyncSelect(), using an empty event set. This stops all asynchronous notifications. Then call recv() as many times as you like. When you're done, re-set the socket's notifications with another call to WSAAsyncSelect(... FD_READ ...). This call will trigger new notifications if there is new data pending, so nothing is lost.

Frankly, it's not worth the effort, since you still need to implement a mini-state-machine anyway. The reason is that TCP is not a message-based protocol; it's a stream-based protocol. It simply sends out a stream of bytes, and doesn't care about the relation of one byte to the next. Thus, even though the server might send out a single chunk of bytes, and do so successfully in one single call to send(), TCP is free to piggyback those bytes onto a pending segment before sending the segment out. Or it's free to break those bytes into multiple segments before sending them out. So, it might take multiple calls to recv(), across multiple network events, before the recipient is able to assemble all bytes together. Thus, when using TCP, it's always necessary for the application to implement some kind of application-level protocol so that the recipient can know when a complete message has been received, and so that it can know where one message ends and another begins.

One common protocol is for the sender to pre-pend each message with an integer which encodes the length of the message. That way, the recipient can tell how many bytes are in the message, and determine when the message is received completely, such that any other bytes received at the end must belong to a next message. Note that TCP might break up the integer too (if it's more than one byte), so your mini-state-machine needs to confirm that all four (say) bytes of the integer have been received before acting on them.

Mike

For transfer of large files, send the length of the entire file just once, at the beginning. On the recipient's side, at each call to recv(), whatever is recv'd should be stored to a local file. It doesn't matter how many bytes are received in each call to recv(): simply monitor how many bytes have actually been received, and stop calling recv() when you have received all of the file's content, as indicated in that very first transmission.

See http://www.codeproject.com/internet/SocketFileTransfer.asp , which uses synchronous sockets, but which implements the "send the length just once at the beginning" technique.

Mike

You should not try to receive the whole file in one chunk, nor should the sender try to send it that way.

The sender should send the file in reasonably-sized buffers, and the recipient should do the same. They do not need to use the same-sized buffers. "Reasonable" means something like 8K or 16K bytes.

Read the linked-to article, which explains this.

Mike

Slightly different issue now. Previously, I was using an enum to define what sort of packet was incoming. for example
enum message_type { MSG_ERR = 0, MSG_LOGIN = 1, MSG_LOGOUT = 2, MSG_TEXT = 3, MSG_FILE = 4 };
I am, however, now doubting this to be a complete safe way of marking a packet type. Various C++ implementations could use different-sized data structures to store the enumeration. So am I right in that I should convert my enum type into a known-sized data type (char or short, for instance) before committing that to network byte-order (if > 1 byte) and calling send()

Thanks once again for your advice. I now simple check my expected data length against SO_MAX_MSG_SIZE and only recv() the minimal value of the two.
I think SO_MAX_MSG_SIZE is the size of a maximum UDP datagram. If so, then it's unrelated to TCP transmissions and the use of this value in this context is not sensible.

Mike