> Which raises the interesting (to me anyway) question: Is there value in
> considering a new protocol, layered on top of TCP, but beneath new
> applications, that provides an "association" the life of which transcends
> the TCP transports upon which it is constructed?

been there, done that.  yes, it is valuable.  but it is expensive
in terms of the amount of protocol overhead and support that you 
need to make it work reliably in the face of various failures.
and it can be slow to recover from such failures.

for instance, you have to build your own data acks on top of TCP,
because if the other end of a connection changes IP addresses you
cannot assume that any data already acknowledged at the TCP level
was actually received by the application at the other end...and 
you therefore have to keep track of data that is unacknowleged by the 
other end in case you have to resynchronize.  

and you need above-TCP keepalives and redirects.

and you need a separate mechanism to keep track of the current
IP address and port number for each of your connection endpoints...
and which gets updated independently (in case your connection
with a peer drops before it has a chance to tell you where it's
moving to)  this separate mechanism has its own failure modes, 
and parts of that mechanism might also be mobile.

if you had to build mobility entirely at the above-tcp level
this might be a useful approach.  but there are better ways to 
implement mobile networking.

Keith

Reply via email to