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,
There is a protocol design that did this, but we tend to shield our eyes
when we look that way - OSI Session layer. It was a hideous thing indeed
to read on paper and way overburdened with options. But when one got down
to the wire, the actual protocol traffic was small. It didn't try to do
any kind of reliability or sequencing or even sensing that a transport had
died. Rather it maintained a sequence of restart points - and it was only
at those points (which were triggered by the application saying "mark this
point") that there were things that could be called "acks".
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
I bet Marshall Rose has some good comments on this as he actually went and
did some of this.
(By-the-way, I'm not in any way suggesting OSI Session, I'm only trying to
learn from the past.)
--karl--