[Gllug] sorts of ports

[Nix]

On Sun, 9 Sep 2001, Kieran Barry gibbered:
> Actually, no. TCP and UDP allocate 16 bits in their headers for ports.
> That would not be enough for a strings based system. And you really
> don't want to have redundancy in the headers.

Quite so! (One of the problems with IPV4 is that some of the headers
have fields in which are, er, not terribly useful unless you're running
some kind of military site; e.g. the `Precedence' field (note the names
of the possible values!), the `Security' options (`Unclassified' through
`Confidential, `EFTO', `MMMM' and lots of other military designators all
the way to `Top Secret')...

>                                               For example, DNS is highly
> tuned so that data plus headers always come in under 576, which is the
> largest packet which can't be fragmented. (Fragmentation is apparently
> quite expensive)

Not true. Packets <576 bytes are sent via UDP; packets greater in size
than that are sent via TCP on the same port (which is of course more
expensive because of the connection setup and teardown
overhead). Firewall admins who don't realize this often block port 53
TCP, whereupon DNS lookups for long names, or with a lot of additional
info in the response, fall over :(

>> Surely it caters in theory for an _infinite_ number of "ports" - if you
>> run a server called "asdfasdf", this string *is* the port, and just
>> looks for/is sent IP packets with "asdfasdf" in the header.
> 
> This would be a definite advantage. On the minus side, it would be far
> more likely to have probs with typos.

And it means that

- TCP and UDP header parsing code can now have buffer overflow bugs and
  yet more classes of malformed-packet attack, and that corrupted packets
  can cause even more amusing havoc than they already can (although the
  checksums make this latter less important)

- the headers get bigger because of the need for a prepended length or
  terminator byte on the string

...

In practice, the `shortage' of ports (only 2^32 * 2^32 * 2^16 * 2^16
permitted) is not much of a problem; even 2^16 fully-sized socket
receive and transmit buffers would overflow the memory of all but the
largest modern machines (2^32 bytes, that would be; 4Gb of nonswappable
RAM, ouch).


Besides, any string-based system's users would naturally (one hopes)
search for an efficient encoding of the names. A maximally efficient
encoding is a packing of names into the available bitspace with no gaps;
i.e., er, exactly the same numeric coding we've got now, only
variable-length.

Not much of a gain ;)

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug