[RESOLVED] Dealing with Async sockets (TCP)

[Grofit]

Hey,

I just wanted to ask about something which im a little confused about at the moment...

When I have setup my socket (bind/listen then beginaccept) and i have a client connect up, the client will connect and then with the resulting socket have beginrecieve() called.

Now BeginRecieve takes a buffer and offset and a load of other stuff, some examples online mention that you may not recieve all your data at once so you will need to keep re-filling the buffer until you have got the data you need. This is the bit im flakey on...

When i set a buffer size, lets say byte[1024] and there is only 32 bytes of data, am I guaranteed that i will get all that 32 in one recieve? I assume im meant to keep checking the EndRecieve()'s returned int to see if its given me all the data i need?

Then im also confused that if i have the same 1024 bytes, but then for some reason someone sends over 2048 bytes of data, will it just fill the 1024 and then somehow notify how much is left to be sent?

Finally would it even combine 2 requests, or does TCP guarantee that it will do it one at a time, and not start a new request until the first one is dealt with?

I have tried looking online but i cant find something that specifically answers these questions.

[Mutant_Fruit]

The only thing TCP guarantees is that you'll get all your data and it will arrive in the same order it was sent.

There is only one thing you can rely on. A call to BeginSend or BeginReceive will always transmit/receive at least 1 byte unless there's an error. After that you're on your own. From TCPs point of view there are no 'messages' it's just a bunch of bits floating across the wire. i.e. if the server does: Send (32bytes) Send (32bytes) you could receive 1 byte or you could recieve 57, or the full 64. Who knows. It's up to you to deal with that.

[Grofit]

So based on your last example there, when you send over 32 bytes then send another 32 bytes, am I right in saying you could get up to the whole 64 bytes at once as one big receive?

I was originally under the impression that it would only do one send at a time, so if you sent over 32 bytes it may only send them 1 byte per receive but it would tell you in some way that you still had 31 bytes left, so you at least knew how long until the end of the given message, then it would start up again on another...

I know this is kinda going off on a small tangent here, but how do people generally deal with this sort of thing, as although its all just bits on a wire, im sure all developers have some logical sort of grouping of the bytes, so you want to handle each logical group of bytes individually... So if you sent over "/load something" then "/quit" you would want to handle each individually, but you could recieve "/load som" then "ething", "/quit"...

so it seems a crazy bag of madness trying to work out how to handle your packets, but im sure this must be a VERY common problem, so im assuming there are some *common* methods to do this sort of stuff, any advice on that would be awesome.

[Mutant_Fruit]

So based on your last example there, when you send over 32 bytes then send another 32 bytes, am I right in saying you could get up to the whole 64 bytes at once as one big receive?

Yup. Or you could get 64 one byte receives.

I was originally under the impression that it would only do one send at a time, so if you sent over 32 bytes it may only send them 1 byte per receive but it would tell you in some way that you still had 31 bytes left, so you at least knew how long until the end of the given message, then it would start up again on another...

There's so many layers of caching and intermediate routers that this behaviour is impossible to get without completely nuking performance back to 1960 levels Or you could use UDP which has the concept of 'messages' of specific length and lose all the benefits of TCP (actually being able to guarantee the message is delivered.

im assuming there are some *common* methods to do this sort of stuff, any advice on that would be awesome.

Simplest and probably most common method is length prefixing.
<4 byte length><message><4 byte length><message>

where 4 byte length tells you how long the message is.

[Grofit]

Thats what i used on one of my previous TCP apps, so i had a custom header and just told it the message type and message length...

A guy i was talking to recently brought up the subject of MUDs and one of my older (MUCH OLDER) projects was quite Mud-esque but worked with a custom client, so i was thinking about maybe improving some of the back end stuff and changing it to do more text based stuff, but from what ive read MUD stuff need to work with even the most basic Telnet client, and (again from my limited understanding of it all) to do that you cant pass around custom headers it just needs to be raw data stuffs and you just pass back strings (although i believe there are some custom protocols for it now)...

It all sounded fairly interesting so started then realised i was a bit stuck on how to approach the same problem without custom headers...

[Mutant_Fruit]

I'm not familiar with 'MUD' in this context, what do you mean?

[Grofit]

Oh sorry Multi User Dungeons, just text based MMOs really... back from ye oldy computing days...

Basically its just something that has to work with a really basic telnet client...

[DataMiser]

I typically use a terminator character on the end of the send like ASCII 4 for example. Then in my code that reads the data from the port I check to see if I have gotten the terminator yet and if not then I save what I did get and wait for more until I either hit my idle timeout or have received the terminator. Or if I am doing a binary file I will send a header that tells the receiver how many bytes to expect.


In the case of a 1024 buffer you should not receive more than 1024 in a single read but any amount of data can be sent. It is up to you to know when it has all arrived.

[Grofit]

Hey,

Yeah thought about putting a token on, i just wondered how they did it back in the day... well my main question has been answered so im gonna go do some more research on MUDs and see how they communicate in more detail...

[jduncanator]

So what is the differnece between this and winsock in terms of recieving entire buffers?