Re: [Netconsole-devel] Protocol notes

[H. P. A. <hp...@tr...>]

li...@ho... wrote:
> 
> > I was considering it, but it adds a lot of complexity for what seems to
> > be very little gain.  In the end I think the solution I came up with is
> > cleaner.  Having a header end pointer so we can add new header fields in
> > the future might be a good idea, though.
> 
> How about IP-style options?
> 

Painful to parse.  I'd like to avoid it.  Fixed-field offsets; even if
truncated by a data pointer, is a helluva lot easier to deal with.

> > I was thinking about having a flags field in the header to denote that
> > sequence numbers are lost -- one bit to indicate "my own sequence numbers
> > have been reset" (START OF STREAM - typically issued when starting a new
> > boot loader level) and one bit to indicate "I don't know where you are in
> > your stream."
> 
> Okay, so we have a SYN bit and (the inverse of) an ACK bit.
> Oh, above you've suggested a data pointer.
> 
> The UDP header gives us two port numbers and a checksum.
> 
> We already have two 32-bit byte checksums.
> 
> Remind me again why we don't just use TCP?

Once again, it will not handle interrupted connections (server reboots,
buffer overruns) correctly -- in fact, it would have disastrous effects. 
Saying you can have a small TCP implementation is not good enough -- the
OS on the server will implement TCP, not the small TCP derivative capable
of handling interrupted connections.  This is reason for not using TCP. 
That something looks a lot like TCP doesn't mean TCP is the right answer.

Once you cannot use TCP, you don't need to put in the things you don't
want into it.

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Source Port          |       Destination Port        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Sequence Number                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Acknowledgment Number                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Data |           |U|A|P|R|S|F|                               |
>    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
>    |       |           |G|K|H|T|N|N|                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Checksum            |         Urgent Pointer        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> > I don't know if this is a feasible option, mostly because I worry about
> > it requiring too much state at the server (which could cause restart
> > problems.)
> 
> It does require that the server ping on startup.  It can back off dead
> clients pretty severely after a while.  They're supposed to send packets
> themselves on startup.

I don't think we want to let the protocol back off quite as far as TCP
would.  Proper behaviour over high-latency/low-bandwidth links is
explicitly *not* a requirement.

	-hpa

-- 
<hp...@tr...> at work, <hp...@zy...> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt