[erlang-questions] : : : : : sctp_peeloff() support in OTP

[Valentin Micic]

> The question remains if {active,true|false|once,Stream,Pid}
> with the side effect that while any stream processor is active
> data flows in on all streams and is buffered in the
> dispatcher (Port or PID) - only if all stream processors are
> passive would the flow be blocked, would be useful?
> That would be a complicated concept. What do you think?

You are absolutely right -- it may be quite complicated; thus, for the time
being at least, not really worth it. This becomes more obvious if you
consider how easy it would be to achieve such functionality outside of a
driver.

There are few things regarding current implementation that would require
your attention more urgently. My view is that one should start by
consolidating current support and RFC describing SCTP socket API. There are
few inconsistencies (in terms of semantic) that I've picked up by just
sporadically reading the RFC. There is a good chance that there are more of
these, should one read RFC with a bit more dedication.
For example, quote:

	"Note, the send() and recv() calls may not be used for a one-to-many
style socket"

Chapter 6.1, page 44.

Ibid. you would be able to find hints that send() and recv() should be used
only to access basic SCTP features (e.g. call to SCTP API send() does not
allow specification of the stream, thus always uses a default stream 0).

I know that send() and recv() functions implemented by gen_sctp are not
really the same calls as specified in RFC, but why not? We can fix this
while SCTP is still relatively "young", but the main challenge is how to
achieve that and still maintain vertical compatibility with existing
applications. Well, maybe you should start a new implementation using a
different name, and, why not: sctp?

Now, let me get back to earth ;-)
Or maybe not just yet:

> ... One-to-many associations.
> Multi-homed endpoints. Packeted messages...
> Those would be important for the Distributed
> Erlang protocol. It is unclear if the streams
> would be useful.

Let Erlang evolve. From the top of my head: authentication and connection
management may be handled using a dedicated stream; and how about mnesia
replication or, even better, common replication service that could be
developed? Or a stream per-scheduler in SMP environment (this one requires a
bit more thinking, I suppose)?

Kind regards,
V.