Sridhar Samudrala wrote:
Your AIO-TCP looks pretty similar to the partial reliablity extension to
SCTP that allows an SCTP endpoint to signal to its peer that it is no longer
going to retransmit certain messages and should skip past those messages.
Damn, so it's not such a crazy idea after all :-)
Something like this would be useful for the sender side, if the
receiver can't figure out on its own that it shouldn't wait for
the data to arrive. (And, assuming that the sender skips data by
leaving a gap, not by filling it with other data, which seems
like a reasonable assumption if we use AIO-TCP at both ends. If
the receiver may use regular TCP, the sender would have to try
to fill the missing part, which can be hairy, particularly if
some of the data-to-be-dropped has already be sent.)
Clearly, any such thing on the sender side would need to have some
means to detect that the receiver can recover from segments that
are never sent.
Is a concrete API for this functionality described somewhere ?
(I only skimmed through the RFC, but the API mentioned there
looks more like an abstract one.)
I like the term "partial reliability" :)
Thanks,
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
On Wed, 11 Aug 2004, Werner Almesberger wrote:
Sridhar Samudrala wrote:
quoted
Your AIO-TCP looks pretty similar to the partial reliablity extension to
SCTP that allows an SCTP endpoint to signal to its peer that it is no longer
going to retransmit certain messages and should skip past those messages.
Damn, so it's not such a crazy idea after all :-)
Something like this would be useful for the sender side, if the
receiver can't figure out on its own that it shouldn't wait for
the data to arrive. (And, assuming that the sender skips data by
leaving a gap, not by filling it with other data, which seems
like a reasonable assumption if we use AIO-TCP at both ends. If
the receiver may use regular TCP, the sender would have to try
to fill the missing part, which can be hairy, particularly if
some of the data-to-be-dropped has already be sent.)
Clearly, any such thing on the sender side would need to have some
means to detect that the receiver can recover from segments that
are never sent.
Is a concrete API for this functionality described somewhere ?
(I only skimmed through the RFC, but the API mentioned there
looks more like an abstract one.)
There is a sockets API extensions for SCTP draft that describes a
way for an app to specify timetolive value for a message.
This can be done using the standard sendmsg() with a control
mesage of type SCTP_SNDRCV.
Also a new API sctp_sendmsg() can be used which has timetolive
as an argument.
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt
-Sridhar
I like the term "partial reliability" :)
Thanks,
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
On Wed, 11 Aug 2004, Werner Almesberger wrote:
Sridhar Samudrala wrote:
quoted
Your AIO-TCP looks pretty similar to the partial reliablity extension to
SCTP that allows an SCTP endpoint to signal to its peer that it is no longer
going to retransmit certain messages and should skip past those messages.
Damn, so it's not such a crazy idea after all :-)
Perhaps not for SCTP. I'd love to see a good AIO API for TCP, but if what
you are describing is implemented, the resulting protocol would be
something other than TCP. There are some RDDP people talking about
similar things, and it is quite controversial within the IETF.
It might be easier to focus on SCTP. This is what it was designed for.
-John