Results 1 to 28 of 28

Thread: [Guide] ]Winsock] Packets Sticking together?

  1. #1

    Thread Starter
    Super Moderator
    Join Date
    Dec 2003
    Posts
    4,787

    [Guide] ]Winsock] Packets Sticking together?

    Ok here is another quick guide demonstrating what to do if your data is getting 'stuck' together,

    I use this method for most of my winsock Applications,

    Thanks

    PINO
    Attached Files Attached Files
    Last edited by Pino; Jan 12th, 2005 at 12:42 PM.

  2. #2
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    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.
    an ending

  3. #3

    Thread Starter
    Super Moderator
    Join Date
    Dec 2003
    Posts
    4,787
    fair comment, i'll add it to the document as soon as i get chance

  4. #4
    Super Moderator Wokawidget's Avatar
    Join Date
    Nov 2001
    Location
    Headingly Occupation: Classified
    Posts
    9,632
    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.

    Woka
    Attached Files Attached Files

  5. #5

    Thread Starter
    Super Moderator
    Join Date
    Dec 2003
    Posts
    4,787
    whenever i have created muliplayer games or chat rooms etc i have allways used that cod and it has never failed me, i dont understand what you mean?

  6. #6
    Super Moderator Wokawidget's Avatar
    Join Date
    Nov 2001
    Location
    Headingly Occupation: Classified
    Posts
    9,632
    Hehe...same thing in 2 threads.

    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

    Woof

  7. #7
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    "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..
    an ending

  8. #8
    Hyperactive Member Vishalgiri's Avatar
    Join Date
    Oct 2003
    Location
    India
    Posts
    345
    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 ).
    ---------------------

  9. #9
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    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.
    an ending

  10. #10

  11. #11
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    Which has no definite size.
    an ending

  12. #12

  13. #13
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    With the Winsock Control?
    an ending

  14. #14

  15. #15
    Super Moderator Wokawidget's Avatar
    Join Date
    Nov 2001
    Location
    Headingly Occupation: Classified
    Posts
    9,632
    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.

    I lied, the "packet" size is in fact:

    (debug.print results)

    8192
    8192
    8192
    8192
    8192
    etc

    Just tested it by sending a 9mb file.

    Woof

  16. #16
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    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.
    an ending

  17. #17
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    addition:

    * is to send a maximum of 4k per send() call

    ..and to receive a maximum of 4k per recv()

    (or 8k, or whatever).
    an ending

  18. #18
    Super Moderator Wokawidget's Avatar
    Join Date
    Nov 2001
    Location
    Headingly Occupation: Classified
    Posts
    9,632
    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

    Woof

  19. #19
    Fanatic Member
    Join Date
    Dec 2003
    Posts
    703
    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.
    an ending

  20. #20
    New Member
    Join Date
    Feb 2006
    Posts
    11

    Question Re: [Guide] ]Winsock] Packets Sticking together?

    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?

  21. #21
    New Member
    Join Date
    Feb 2006
    Posts
    11

    Re: [Guide] ]Winsock] Packets Sticking together?

    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 ?

  22. #22
    Super Moderator Wokawidget's Avatar
    Join Date
    Nov 2001
    Location
    Headingly Occupation: Classified
    Posts
    9,632

    Re: [Guide] ]Winsock] Packets Sticking together?

    it's not per packet.

    SendComplete fires when the whole data has been sent, send progress fires periodically while sending.

    Woka

  23. #23
    New Member
    Join Date
    Feb 2006
    Posts
    11

    Re: [Guide] ]Winsock] Packets Sticking together?

    so send complete is raised when the last bit of data in the stream is sent?

  24. #24
    Super Moderator Wokawidget's Avatar
    Join Date
    Nov 2001
    Location
    Headingly Occupation: Classified
    Posts
    9,632

    Re: [Guide] ]Winsock] Packets Sticking together?

    yes. suprisingly...exactly what you would expect from an event called SendComplete

    It's not going to mean it's 1/2 way through is is

    Woka

  25. #25
    Lively Member
    Join Date
    Aug 2008
    Location
    Between the keyboard and the chair.
    Posts
    122

    Re: [Guide] ]Winsock] Packets Sticking together?

    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.
    Attached Files Attached Files
    If I have helped you out, be a pal and rate the helpful post!

    My CodeBank Submissions:
    Convert Color Values Between Long, RGB and Hex. Updated Sept 25th!
    Update Checker FrameWork

    My WIP Projects:
    Winsock Chat Server/Client Updated Oct 5th!

    Useful Tools:
    Aivosto.com MZ-Tools SysInternals Suite

  26. #26
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: [Guide] ]Winsock] Packets Sticking together?

    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.

  27. #27
    "Digital Revolution"
    Join Date
    Mar 2005
    Posts
    4,471

    Re: [Guide] ]Winsock] Packets Sticking together?

    I used to just delimit data but then realized it's better to just send the length in a header.

    Then it's easy to always send data and have it be 100% reliable no matter if "packets" get joined together, split up, etc.

  28. #28
    Fanatic Member FireXtol's Avatar
    Join Date
    Apr 2010
    Posts
    874

    Re: [Guide] ]Winsock] Packets Sticking together?

    Quote Originally Posted by dilettante View 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.
    cSocket is about 10x less latent.

    Care to qualify your statements about the socket classes you used, or the specific revisions?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width