Re: TCP_NODELAY

Using TCP as a catch all protocol is a bad idea. UDP is not the only other
option either, but happens to be easy to work with from UM in windows.



In your example of an online game, a better solution would be a TCP control
channel + UDP 'action' messages.



It is irreverent to presume that one knows more than the designers of TCP
but dogmatic to assume that they know more that everyone else - especially
since they designed a general purpose protocol and not all purposes are
general!


"Chris Becke" <chris.becke@xxxxxxxxx> wrote in message
news:uQnpRCjGJHA.2408@xxxxxxxxxxxxxxxxxxxxxxx
One could use UDP. and wrap it in a protocol that robustly deals with
dropped packets.
One could re-invent the wheel.
Or, one could just use TCP: Which already deals with dropped packets. And,
usually does so far more robustly than any homegrown solution.

I have yet to see a good example of a UDP based protocol that outperforms
TCP. Only good examples of bad programmers thinking they know more than the
designers of TCP.

"Alun Jones" <alun@xxxxxxxxxxxxx> wrote in message
news:exXs48gGJHA.2580@xxxxxxxxxxxxxxxxxxxxxxx
"Chris Becke" <chris.becke@xxxxxxxxx> wrote in message
news:Oyfso8WGJHA.3664@xxxxxxxxxxxxxxxxxxxxxxx
The first thing you MUST do when setting TCP_NODELAY is wrap all your
sends up as much as possible into a single call to send.

Thereafter however, there is much performance to be gained in particular
application domains by setting TCP_NODELAY. Assuming you are sending less
than ~20Kb per second.

If, for example, you are writing any kind of online game, having the
socket layers hold onto packets for 200ms is unacceptable. Ignoring
actual
network latencies you now have a ~400ms round trip latency on all comms.
Which is now larger than a humans reaction time.

If, for example, you are writing any kind of online game, you don't want
to
be using TCP, because it can _always_ introduce latency (noise on the line
causing a retransmission is just one way to introduce latency). If you
don't
want occasional latency, you must use UDP - and your protocol must
robustly
deal with dropped packets.

I have yet to see a _good_ example of the use of TCP_NODELAY - only good
examples of bad programmers, or good examples of programmers having to
deal
with bad protocol design.


.

Relevant Pages

  • Re: PORT 135 still open with Norton PF 2002
    ... Protocol: ... TCP or UDP ... Remote service: Any Service ...
    (comp.security.firewalls)
  • Re: Allow Wimba Live Classroom via ISA 2004 on SBS 2003
    ... "The wimbamedia client first tries to connect through UDP 5998 then TCP ... Maybe I can get it to work by defining the custom protocol with primary UDP 5998 Send or Send Receive and secondary TCP 5998 Outbound. ... If not a custom access rule, to what rule do I attach the custom protocol? ...
    (microsoft.public.windows.server.sbs)
  • Re: TCP_NODELAY
    ... one could just use TCP: Which already deals with dropped packets. ... I have yet to see a good example of a UDP based protocol that outperforms TCP. ... because it can _always_ introduce latency (noise on the line ...
    (microsoft.public.win32.programmer.networks)
  • Re: how exactly UDP tunneling works...
    ... >that sounds strange because UDP is not reliable protocol opposite to TCP ( ... >many routers allow configuration not allowed UDP to pass because of that). ...
    (microsoft.public.win32.programmer.networks)
  • Re: Firewalls, Ports and Mayhem
    ... What does UDP stand for and what is the differenece ... > UPD and TCP is something called protocols. ... UDP is a connectionless protocol which makes a best effort to ...
    (microsoft.public.windowsxp.security_admin)
Loading