RE: [VANILLA-LIST:3019] technical question

[Trent Piepho <xyzzy@speakeasy.org>]

On Wed, 22 Mar 2000, Chawla, Jay wrote:
> Also, a person who authors a patent is his own lexicographer and grammarian.

That would seem to give them quite the advantage, the ability to after the
fact to decide exactly what there patent does and does not describe.  They can
construct a definition of "aggregation" such that any example of prior art you
may find does not apply, while your client's product still does.

> ftp://ftp.netrek.org/pub/netrek/ ).  Is there any other source code, design
> documents, or instructions that I don't know about?

I would think that the source code is the definitive proof of what netrek does
or does not do.  If you determine that netrek is prior art, you could
establish the date it was created by contacting the appropriate author.  The
client/server separation of xtrek-II, which is when any "aggregation" function
of the server would have been written, was done by Kevin P. Smith in 1989.

> As Dave says, I'm not a TCP/IP guru.  Can I ask you guys a novice question?
> Please correct any mistakes I make and help me out here with my transport
> layer ramblings:
> 
> TCP is a connection oriented protocol -- mail servers use it to send mail
> and IRC servers use it to send messages.  TCP sockets are point to point and
> one-way between two transport-level entities.  You write things to a socket

TCP/IP is two-way, not one-way.  Both endpoints are able to simultaneously
send and receive data.

> whenever you want, and what you're writing goes into a buffer.  So if I send
> 3 IP packets to the socket in a short enough time, they'll all be buffered.

You've already made a big mistake.  One does not send IP packets to a TCP
socket.  The abstraction that TCP/IP provides is one of a byte-steam, there
are no "packets" to the application.  The packets are created in a lower level
by the networking stack.

> Periodically, the buffer is emptied.  So the three IP packets will be

That is somewhat of an oversimplification.  There are number of very complex
rules controlling how the contents of the buffer are separated into packets
and transmitted.  The contents of the buffer are not packets yet, as I said,
but a stream of bytes.  The TCP stack will compose a single packet using some
number of bytes from the beginning of the buffer.  It is entirely possible
that the bytes the TCP stack chooses to form the payload of a single packet
were originally placed into the buffer by the application at different times.

> UDP is a connectionless protocol -- real time applications use it to send
> keystrokes (for telnet sessions), audio information (you can lose some of it

telnet uses TCP.

> Xpilot servers.  If you want aggregation with UDP, you need to do it
> explicitly yourself, so Netrek does it explicitly, i.e. in its own source

With UDP, the application chooses how the data is divided into packets.  With
TCP, the networking stack controls how the data is divided into packets, but
the application does have a bit of control over this.