Fair enough, but it sort of misses the point. The data isn't being "stuck together", because the data is sent in a continuous stream - TCP/IP is a stream protocol. That needs to be clear in the document really, because a lot of beginner winsock programmers make the mistake of thinking one "send" call will correspond to one "receive" call on the remote host.
No offence Pino, but that code won't work properly.
What if the data sent is larger than the packet size???
Have a look at the code inside the Socket class...(not clsSocket)
Look at the code in SendData and mobjSocket_OnDataArrival.
As you can see there is some pretty heft coding to deal with merging packets and stuff
The code attached to this post uses a winsock class
,clsSocket which is a version of the cSocket class available over the web.
However, the senddata and mobjSocket_OnDataArrival code CAN BE EASILY transfered to work on a winsock control in a form.
Just to keep this thread correct, your method works fine...UNLESS the data sent is > 4k (packet size) in which case you need to merge packets back together. Your code doesn't do this, but works perfectly for data < 4k
"Packet size" has no meaning in TCP/IP. Your code *must* assume that the data can arrive in any way it wants (though it's guaranteed to be in order). Unfortunately there's a lot of broken code out there..
Originally posted by azteched "Packet size" has no meaning in TCP/IP. Your code *must* assume that the data can arrive in any way it wants (though it's guaranteed to be in order). Unfortunately there's a lot of broken code out there..
intresting, can you explain?
Regards,
Vishalgiri Goswami
Gujarat, ( INDIA ).
---------------------
TCP is a stream protocol. It works on a stream of bytes - Winsock knows nothing about your application-defined messages/packets. At the transport layer the data is sent in packets, but these don't necessarily have any relation to what you send in a single "send" command.
It's not the winsock control, but the cSocket class that can be used to replace the winsock control. Although I remember exactly the same thing when I used to use the winsock control.
Yeah, exactly. I bet the underlying implementation of the control is to send a maximum of 4k per send() call. It's also receving 4k per recv() (unless there isn't a 1 to 1 correspondence between recv() calls and DataArrived events), but that's not guaranteed anywhere by TCP. It'll likely receive 4k per recv() over the loopback, or over a local network, because there's essentially no over-the-wire delays. Bottom line: Don't ever assume how much data a single recv() call will return with TCP. It may work in testing, but sooner or later code that makes assumptions like that *will* break.
I completely agree with you.
Whenever I use winsock I encode the data so the server knows when it's received it all.
It adds the "packets" together until the whole data has been received.
U see LOADS of users here not bothering with the concatonation of the "packets" and they assume that ALL the data is received in one go.
Keep telling people, but they don't seem to listen
Yup The problem is I think that when people test their code locally, it does work because the data doesn't have to traverse the 'net, but then when it gets released, they get a shock.
So the winsock send_complete event shouldn't be used when recieving data, packets delimited or otherwise - because the send isn't ever complete being that it's a stream?
Initially I thought the send_complete event was for the completion of each 8k packet, but if that's the case then what is the send_progress event for ?
I've attached a class I am using for my current project, and was wondering, does it fix the packet problem? Logically in my mind, it should work for both Split Packets as well as Appended Packets. Using the term Packets loosely of course.
PS. Sorry for re-opening an OOLD post.
If I have helped you out, be a pal and rate the helpful post!
If everyone simply stopped saying "packets" we'd all be way ahead.
The Winsock control's SendComplete event is raised when the Winsock control can accept another SendData without blocking. It does not mean that the buffers are completely empty.
You couldn't pay me to use cSocket/cSocketMaster. They are quite flawed in several ways the authors were never able to correct and I gave up tinkering with them myself years ago. By VB6 SP6 the Winsock control was an extremely robust tool.
The 8K that keeps coming up is the underlying socket's TCP buffer size. The Winsock control uses additional paged memory buffers in front of the socket's non-paged buffer for output to help smooth out operation in VB6. It relies on the 8K input buffer though for receiving, which is why you see DataArrivals of up to 8K but no larger.
If everyone simply stopped saying "packets" we'd all be way ahead.
The Winsock control's SendComplete event is raised when the Winsock control can accept another SendData without blocking. It does not mean that the buffers are completely empty.
You couldn't pay me to use cSocket/cSocketMaster. They are quite flawed in several ways the authors were never able to correct and I gave up tinkering with them myself years ago. By VB6 SP6 the Winsock control was an extremely robust tool.
The 8K that keeps coming up is the underlying socket's TCP buffer size. The Winsock control uses additional paged memory buffers in front of the socket's non-paged buffer for output to help smooth out operation in VB6. It relies on the 8K input buffer though for receiving, which is why you see DataArrivals of up to 8K but no larger.
cSocket is about 10x less latent.
Care to qualify your statements about the socket classes you used, or the specific revisions?