Send and Receive Data Bigger than Buffer Size with MFC CAsyncSocket

[leovailati]

Hello,

I have a small client-server project that is meant to be a proof of concept to a larger project in the near future. It's about real time data aquisition: data collected in site by the server is transmited via network to one or more clients. I'm using the standard MCF sockets: CAsyncSocket to make the communication backend.

The problem: When "the datagram is larger than the buffer supplied, the buffer is filled with the first part of the datagram, the excess data is lost"[1].

My solution would be send first the total size of the data in a small and default message type and then start sending the data in fragments with the same size as the buffer; but I wonder if there are any better - or more formal - solutions for that because I feel like I'm reinventing the wheel.

Thanks in advance.

[1] http://msdn.microsoft.com/en-us/library/ct7d990b%28v=vs.80%29.aspx

[kbw]

My solution would be send first the total size of the data in a small and default message type and then start sending

That's a well known solution and works reliably.

[leovailati]

Thanks for your reply, kbw.
But what I actually did was creating a class specifically for receiving data: when datagram is larger than receiving buffer, data is concatenated until a packet smaller than buffer size is received. I got this idea from the data receiving code in the MSNPSharp project. (http://code.google.com/p/msnp-sharp/ ).

This solution - as usual - got me another problem: apparently the WSAEMSGSIZE error is not being received (Receive function should return it), which would be necessary to see if the data received is really larger than the buffer (and was fragmented) or it has exactly the size of the buffer.

[kbw]

But what I actually did was creating a class specifically for receiving data: when datagram is larger than receiving buffer, ...

That's not what I was endorsing. You're making a rod for your own back with this larger send than recieve problem.

First, there isn't a wealth of information out there on MFC socket stuff. It's a further abstration on an abstraction on a network protocol and isn't worth the effort learning it. Personally, I wouldn't bother with that and would consider using select() for async socket use. Or if you really want to try to squeze performance out of the platform, use Winsock 2 directly. You gain nothing from using MFC.

Second, the sender/receiver need to agree on how much to send. If you're going to send the length in a fixed length header followed by the variable length body, then do that. If you do that, I can't see how you can get a send/recv size mismatch.

[leovailati]

Again, thank you for your reply kbw.

I know that wasn't what you were suggesting, but in this specific case it would be a waste of time keep sending the data size before the data itself. As I said in the first post, the application will be used for data acquisition (and remote analisys), this means the structure sent by the server has (almost) always the same (big) size.

Nevertheless, I couldn't bypass the last problem I commented: the error code WSAEMSGSIZE isn't returned by Receive and neither by GetLastError as it was supposed to. So, since the application might also have to send comments and other special messages, I decided to keep my original (and endorsed by you) idea. Now the send/receivement happens in two turns: one for size (when an int with the size is transmitted and a structure big enough to accomodate the data is created) and one for data (where this structure is filled).

You are also right about the lack of information on MFC sockets and about how badly they were implemented, I will bring your last comment to my boss and discuss changing it to Winsock 2 or another good sockets library (any other suggestion?). Luckly, I kept a strong abstraction layer among the project components and I guess making such change won't be a problem.