Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock
Receive small packets quickly over winsock Receive small packets quickly over winsock
Receive small packets quickly over winsock
Go Back  Xtreme Visual Basic Talk > > > Receive small packets quickly over winsock


Reply
 
Thread Tools Display Modes
  #1  
Old 11-25-2010, 12:01 PM
the master's Avatar
the master the master is offline
Tachikoma
 
Join Date: Mar 2003
Location: Mansfield, UK
Posts: 4,596
Default Receive small packets quickly over winsock


Hi, I've got some client/server apps that need to send small amounts of data (about 50 bytes) really quick. Winsock is quite good at this but if i send the data 2 or more times without waiting then the receiving end appears to buffer it until either i stop sending or the data is large enough to call the dataarrival sub.

I've tried TCP and UDP but both appear to have the same problem. Normally this kind of buffering would be a good thing but in this case each packet needs to be processed separately and as quick as possible.
__________________
"That which seems simple is often overlooked" ~ me
Halloween 2014 Yard Haunt
Halloween Special FX
Reply With Quote
  #2  
Old 11-25-2010, 02:14 PM
Banjo's Avatar
BanjoReceive small packets quickly over winsock Banjo is offline
Hell's Angel

Retired Moderator
* Guru *
 
Join Date: Jul 2001
Location: Yorkshire, UK
Posts: 10,394
Default

Try calling DoEvents after each send.
__________________
A wise one man once said "what you talking about dog breath"
Reply With Quote
  #3  
Old 11-25-2010, 08:10 PM
OnErr0r's Avatar
OnErr0rReceive small packets quickly over winsock OnErr0r is offline
Obsessive OPtimizer

Administrator
* Guru *
 
Join Date: Jun 2002
Location: Debug Window
Posts: 13,774
Default

You can use setsockopt (winsock) API with TCP_NODELAY to disable the Nagle algorithm and winsock will send small packets.

Note that you really should be sending some sort of EndOfPacket delimiter and parsing individual packets.

Edit: You might find this useful: http://www.xtremevbtalk.com/showpost...57&postcount=7
__________________
Quis custodiet ipsos custodues.

Last edited by OnErr0r; 11-25-2010 at 08:18 PM.
Reply With Quote
  #4  
Old 11-25-2010, 08:46 PM
dilettante's Avatar
dilettanteReceive small packets quickly over winsock dilettante is offline
Underclocked lifestyle

Forum Leader
* Guru *
 
Join Date: Feb 2005
Location: Michigan, USA
Posts: 4,529
Default

Nagle doesn't apply to UDP though. If this kind of thing is happening with UDP I'd suspect a simple logic error in the program.

In this scenario I expect Nagle to be an issue as well as the "assuming message boudaries" (packet) fallacy - at least with TCP. There are no "packets" here. TCP is a stream protocol and UDP is a datagram protocol.
Reply With Quote
  #5  
Old 11-26-2010, 01:41 AM
Banjo's Avatar
BanjoReceive small packets quickly over winsock Banjo is offline
Hell's Angel

Retired Moderator
* Guru *
 
Join Date: Jul 2001
Location: Yorkshire, UK
Posts: 10,394
Default

Quote:
Originally Posted by dilettante View Post
In this scenario I expect Nagle to be an issue as well as the "assuming message boudaries" (packet) fallacy - at least with TCP. There are no "packets" here. TCP is a stream protocol and UDP is a datagram protocol.
While this is true, it is also true that the only prevalent network layer these days is IP, which is packetised. So in practise TCP is packetised. Of course, if the lower layers of the network do their job properly then you should never notice.
__________________
A wise one man once said "what you talking about dog breath"
Reply With Quote
  #6  
Old 11-26-2010, 09:33 AM
dilettante's Avatar
dilettanteReceive small packets quickly over winsock dilettante is offline
Underclocked lifestyle

Forum Leader
* Guru *
 
Join Date: Feb 2005
Location: Michigan, USA
Posts: 4,529
Default

But that's totally irrelevant because what people think they mean by "packet" has nothing to do with the IP layer. What they mean is "message" and TCP does not preserve message (SendData) boundaries. "Talking wrong" leads to "thinking wrong."

The Winsock stack vendor community railed against this from almost the earliest days, well before the Microsoft stack became stadnard in Windows: Winsock was a specification from Microsoft back then and not an API.

Surely you've seen The Lame List?

They also tried to address this specifically in Problem 1: Packets Are Illusions.
Reply With Quote
  #7  
Old 11-26-2010, 11:49 AM
the master's Avatar
the master the master is offline
Tachikoma
 
Join Date: Mar 2003
Location: Mansfield, UK
Posts: 4,596
Default

I had already tried using doevents but it gave the same result. The protocol between these applications specifies a message length in the first 4 bytes. When receiving they ignore all bytes until a 255 is received, then they wait for 4 bytes that contain the message length and action etc, then they wait until the message is at the correct length. This removes the need for an "EndOfPacket" (assuming that TCP does its job correctly and doesnt lose anything) and they can handle multiple messages at once.

These apps are being used for controlling devices in realtime (mainly fading lights) so buffering then running all at once causes strange fading patterns.

Ive just looked up setsockopt and it appears to be working perfectly
Thanks!
__________________
"That which seems simple is often overlooked" ~ me
Halloween 2014 Yard Haunt
Halloween Special FX
Reply With Quote
  #8  
Old 11-26-2010, 10:59 PM
mkaras's Avatar
mkarasReceive small packets quickly over winsock mkaras is offline
Ultimate Contributor

Retired Leader
* Expert *
 
Join Date: Mar 2004
Location: Beaverton, OR
Posts: 1,874
Default

Do you assure that none of the data in a message contains a 255 byte? If not then you could have problems if you lose sync with the message stream and you detect one of these "other" 255 bytes and start picking up length information in the wrong place.

Michael Karas
Reply With Quote
  #9  
Old 11-27-2010, 04:40 AM
the master's Avatar
the master the master is offline
Tachikoma
 
Join Date: Mar 2003
Location: Mansfield, UK
Posts: 4,596
Default

Unfortunately that is one downside to this protocol. It's never been a problem with the TCP connection but it has happened when forwarding to the devices. It's very unlikely that it will happen given the handshaking lines and timeouts etc (I've only seen it once in months of usage) but i will be changing the protocol eventually to prevent it and other problems I've found.
__________________
"That which seems simple is often overlooked" ~ me
Halloween 2014 Yard Haunt
Halloween Special FX
Reply With Quote
  #10  
Old 11-27-2010, 05:02 AM
Banjo's Avatar
BanjoReceive small packets quickly over winsock Banjo is offline
Hell's Angel

Retired Moderator
* Guru *
 
Join Date: Jul 2001
Location: Yorkshire, UK
Posts: 10,394
Default

Quote:
Originally Posted by dilettante View Post
But that's totally irrelevant because what people think they mean by "packet" has nothing to do with the IP layer. What they mean is "message" and TCP does not preserve message (SendData) boundaries. "Talking wrong" leads to "thinking wrong."

The Winsock stack vendor community railed against this from almost the earliest days, well before the Microsoft stack became stadnard in Windows: Winsock was a specification from Microsoft back then and not an API.

Surely you've seen The Lame List?

They also tried to address this specifically in Problem 1: Packets Are Illusions.
I didn't state that the packets received would be the same packets sents. The fact is though that no matter what you send, it will be received in a packetised form due to the underlying nature of the network protocols in common use.

I must admit though that I'd forgotten the possibility that someone might not understand the need collate the in incoming data and define their own application level protocol to make sense of it. Haven't been on this forum so much lately to remind me of that.

Not that the OP seems to have this problem though.

PS: No, I hadn't seen either of those links before.
__________________
A wise one man once said "what you talking about dog breath"
Reply With Quote
  #11  
Old 11-27-2010, 04:16 PM
dilettante's Avatar
dilettanteReceive small packets quickly over winsock dilettante is offline
Underclocked lifestyle

Forum Leader
* Guru *
 
Join Date: Feb 2005
Location: Michigan, USA
Posts: 4,529
Default

Quote:
Originally Posted by the master View Post
Ive just looked up setsockopt and it appears to be working perfectly
Thanks!
It sounds like the culprit here was the Nagle Algorithm then. Sends were being clumped together at the sender to avoid excessive protocol overhead "on the wire."

TCP isn't the best choice for "real time" applications. Intermediate network devices such as switches and routers are allowed to "reclump" TCP data as they handle it too, though they seldom add large delays.

You'll find that UDP is often chosen for such things, especially when losing a datagram isn't fatal to the application (streaming audio, etc.).
Reply With Quote
  #12  
Old 11-27-2010, 05:58 PM
the master's Avatar
the master the master is offline
Tachikoma
 
Join Date: Mar 2003
Location: Mansfield, UK
Posts: 4,596
Default

I did look at UDP a while ago hoping it would solve the problem. I prefer TCP because it's more reliable. In this case I would rather not lose any data. It doesn't have to be portable so as long as it works for me then I don't need to worry.

As part of the protocol modification I will look at using TCP and UDP together. The most important data is only sent once wheras it doesn't matter too much if the high speed data has a few problems as it's mostly used to overwrite the previous data. I could always send the final command of any high speed data through TCP ensuring that it gets there correctly. All I would need to do is ensure the data over TCP doesn't get processed before the UDP data.
__________________
"That which seems simple is often overlooked" ~ me
Halloween 2014 Yard Haunt
Halloween Special FX
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock Receive small packets quickly over winsock
Receive small packets quickly over winsock
Receive small packets quickly over winsock
 
Receive small packets quickly over winsock
Receive small packets quickly over winsock
 
-->