[ProgSoc] TCP quiz. HELP!!!!
raz at raz.cx
Mon Jun 14 17:02:02 EST 2010
Note that TCP is not at "fault" here. If you are concerned about every
last bit's worth of bandwidth (e.g. CSD on mobiles, NASA's deep-space
network, ...) then your environment is not suitable for contemporary
applications anyway, whether for small amounts of data (telnet) or large
(http). Bandwidth efficiency, responsiveness and reliability are
somewhat at odds with one another but for most applications for which
reliability is a strong requirement, the minute amounts of bandwidth
wasted in TCP overhead are an acceptable (indeed, probably inescapable)
cost, even if they're orders of magnitude larger than the payload.
Exercise for the reader: how many _tonnes_ of mass have to be lifted to
get 1kg of payload into geostationary orbit with the aid of the STS
On 06/06/2010 19:19, jedd wrote:
> On Friday 04 June 2010 09:57:43 Noah O'Donoghue wrote:
>> If TCP sends packet for packet wouldn't that require nearly equal bandwidth
>> each way? At least for small packets..
> Do not assume that because it's hugely popular, TCP/IP is incredibly
> well designed (with the potential caveat 'for the networks it now
> finds itself on').
> Mind, OSI was probably worse.
> As has been observed, window scaling and selective acknowledgements
> have been introduced to alleviate some of the observed problems.
> And as you observe, for small data your I/O approaches equivalence.
> Consider a login prompt on a remote box - for every character that
> I type I'm sending a 41 (?) byte packet, and it's sending a 41-byte
> packet back. At the end of it, I've sent four or five* characters of
> 'useful' information, but there's been 160-200 bytes in and out.
> This is why we like big MTU's and non-chatty protocols. Regrettably
> we're working against developers who have other ideas here. ;)
> * You might count CR as useful in this context.
> Progsoc mailing list
> Progsoc at progsoc.org
More information about the Progsoc