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--