ietf
[Top] [All Lists]

Re: utility of dynamic DNS

2002-03-04 04:40:03
On Fri, 1 Mar 2002, Keith Moore wrote:

There is another alternative way to solve this: an "assocation" layer
above TCP that allows application/client-to-application/server 
communications to span a sequence of lifetimes of underlying transports.

Been there, done that.  There are a lot of problems with that approach,
including that you basically have to implement TCP all over again above
the TCP layer, and you have to be able to recover from outages caused by
multiple parties moving at the same time.  You can make it work as a
sort of kludge,  but it's hard to make it robust, and it doesn't make 
good architectural sense.

No need to do "TCP all over again".  That would be very silly.  And it 
would be wrongly done.

But one need not do those things to construct an association protocol that
allows application associations to span the lifetime of transports 
connections.

All that is needed is to a means through which the two applications can
agree upon a marker - simply a name or number of their chosing with no
external semantics.  The marker indicates something of meaning to the two
applications.  For example, one can have a mark composed of a
byte-sequence "got e-mail 5".  If during the transfer of something the two
applications consider to be "e-mail 6" the underlying transport dies, then
they pick up at whatever point "got e-mail 5" means to themselves.  The 
resumption point has nothing to do with TCP sequencing semantics at all - 
unless the applications chose to use that.  But they can just as easily 
use transaction numbers or whatever else is convenient for them.

I am rather wondering at your comment about "multiple parties moving at
the same time" - a marker/assciation protocol is purely bi-lateral - it
involves only the two communicating applications and nothing else.

And there is no need to reinvent TCP, in fact there is no need for the
this transport-spanning part of the protocol stack to buffer data at all.

With markers, machines can move around, letting the transport/TCP
connections lapse and die as their underlying IP addresses become no
longer topologically useful, reestablishing new transports with new
addresses, and pick up from the last agreed-upon marker.

It's a whole lot easier - and a lot more in tune with end-to-end semantics
- than the juggling games that we call mobile IP.

                --karl--






<Prev in Thread] Current Thread [Next in Thread>