Re: Internal TCP/IP send buffer?
From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 10/22/04
- Next message: Alun Jones [MSFT]: "Re: UDP Broadcast issues."
- Previous message: Alexander Nickolov: "Re: Help a sample about send file through Socket in C#!"
- In reply to: Marton Anka: "Re: Internal TCP/IP send buffer?"
- Next in thread: Alun Jones [MSFT]: "Re: Internal TCP/IP send buffer?"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 22 Oct 2004 11:06:00 -0700
You'll need to devise a higher level protocol to detect stale data,
and that has to be decided at your proxy server. Note there's
little you can do about the network latency over the intenet. It's
measured using the roundtrip for a packet to go to the destination
and another to be sent back and received at the origin. TCP
maintains it as part of its implementation, but you can't get a peek
at it (or at least I don't know how to do it under Windows, but
I've done it under Linux). You can do this yourself too, using
UDP or a separate TCP connection to the target and periodically
(say every 10 seconds) sending small packets to which the server
responds right away, then measuring the roundtrip time as the
difference between the receiving and the send times. It'd not be
as accurate as the TCP-level measurement, but it gives you
a better idea how your data behaves. Finally, since the two
directions of your communication may have different latencies,
half the roundtrip is not exactly the time it takes for your packets
to be delivered. Additionally, the data size (especially over slow
connections) constitutes a completely different source of latency.
If your packets are infrequent, the bandwidth latency is of little
concern to you, but you should always be mindful of other
connections stealing the bandwidth under you and thus imposing
unexpected latency.
Now, on your setup. If your two servers are located across
the Internet, you should be worried about the latency. However,
this latency is not due to buffering at either end - it is the latency
of the chain of routers between the two destinations. Each router
maintains its own queue which you have no control over. When
such queue fills, the router is overloaded and starts dropping packets.
Even when it's not opverloaded, it's queue is partially full thus
introduces small latency. The longer the count of intermediate
routers, the higher the latency of the entire connection as these
add up.
Coming back to dropped packets - TCP will retransmit these
when they are detected using exponential backoff between
resends. There are optimizations like fast retransmit (when the
same data in the stream is confirmed 3 times in a row), but these
are still much sower than the connection latency. And this is your
real problem with TCP - you can't drop the data and continue
as you'd do with UDP. That's why TCP is not suited for real-
time communication and UDP is preferred. Any data you've sent
after the lost packet will be queued at the other end and not
delivered until the lost packet is retransmitted and delivered.
-- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD email: agnickolov@mvps.org MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== "Marton Anka" <marton@03am.com> wrote in message news:e8CCHxFuEHA.3860@TK2MSFTNGP09.phx.gbl... > Alun, > > Thanks for the reply. > >> Here's the first clue - any time you talk about disabling Nagle, you have >> to wonder if TCP is the right protocol for you. > > No - Nagle can be both a blessing and a curse. That's why there's an > option to disable it. It's simply there to help with bandwidth efficiency > when throughput is preferred over latency. In this case I need to minimize > latency. > >> Probably the TCP window negotiated between client and server on >> connection. You shouldn't do anything to work around this, it's a >> valuable property of TCP. > > I'm not trying to work around them. If the buffer I'm talking about is > indeed the TCP window, then how do I go about adjusting its size for the > current connection? > >>> Can this internal buffer be disabled or limited in size somehow? >> >> That will not solve your problem. Your problem is that you are asking >> for TCP to be made to behave like UDP. It would be better to use UDP >> instead. > > Actually, it will solve my problem. If you can show me where UDP > guarantees delivery, orders packets and controls data flow then yes, it > would be better to use it. At this point however it seems like I'm asking > for this non-existent UDP to behave more like TCP. So I might as well use > TCP the way it was intended to be used, but how can I control that pesky > buffer? > > To describe the situation: > > Client is connected to Proxy over the internet, possibly with a very slow > connection. Server is connected to Proxy over gigabit ethernet. Server is > sending small chunks of data to Proxy that gets forwarded to Client. TCP > buffering between Proxy and Server is causing problems with the data being > out of date by the time it is recv()-d by Proxy. Proxy has no knowledge of > the protocol used between Client and Server, and even if it did it could > not do anything with it as the data is encrypted. > > Thanks, > > Marton >
- Next message: Alun Jones [MSFT]: "Re: UDP Broadcast issues."
- Previous message: Alexander Nickolov: "Re: Help a sample about send file through Socket in C#!"
- In reply to: Marton Anka: "Re: Internal TCP/IP send buffer?"
- Next in thread: Alun Jones [MSFT]: "Re: Internal TCP/IP send buffer?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
