From: Frédéric B. <fre...@fr...> - 2012-08-28 14:41:46
|
Le 28/08/2012 13:42, Trevor Davel (Twylite) a écrit : > Hi, > > On 2012/08/28 12:21 PM, Frédéric Bonnet wrote: >> The layering is as follows: >> >> - SCTP sockets have one-to-many associations >> - SCTP associations have one or several concurrent streams >> - SCTP streams convey sequences of messages >> - SCTP messages are streams of bytes > SCTP messages are groups of bytes. RFC2960 makes this clear and > requires fragment reassembly and delivery of the message as a unit. > RFC4960 adds support for partial delivery where the message exceeds the > buffer size. RFC2960 is explicitly obsoleted by RFC4960. And you're talking about protocol implementation level here. The same goes with TCP. Unless you're planning to write a protocol stack these points are irrelevant to an application programmer that only deals with associations, streams and messages. > You _can_ treat any group of bytes as a stream. You can wrap a stream > interface around a ByteArray, a string, or a datagram. There are times > when it may be very convenient to do this, but there are also times when > it would be inconvenient to only be able to handle a string or datagram > has a stream. If a string or datagram API only presented a stream > interface, there would inevitably be a wrapping API developed to treat > the string or datagram as a group of bytes rather than a stream. You mean, something like: set string [$channel read] Overly complicated, especially compared with [encoding] considerations /sarcasm > It is possible to layer stream-based IO on top of datagram-based IO in > several ways (a stream fragmented across datagrams, or a stream > interface to the contents of a datagram), and it is possible to layer > datagram-based IO on top of stream-based IO (using a framing protocol > such as HTTP chunking of BEEP/BXXP). The choice of what to put on the > bottom depends on the "natural" representation for the protocol - the > least impedance mismatch - and the most common high-level use-cases. However it is not possible to implement a string-based model over a message-based model when said messages are potentially unbounded streams. >> 4. Without message boundary/record marker support, one single Tcl >> channel per SCTP message. Channels are pure streams on input& output. >> No metadata needed. Peer info, stream ID and message ID are set at >> channel creation time. A callback is needed for every new channel (= >> incoming message). >> >> >> Solutions 1/2/3 not only require changes to the channel infrastructure, >> but they shift the burden of reassembling incoming data from the core to >> the application. Solution 4 requires no change to the current model. > Sounds like you're arguing for solution 4; am I correct? > > Which means that you can implement SCTP right now within the Tcl channel > model, probably as a new type of [socket] (with minor extensions to the > [socket] API). Problem solved. As said to Donal, see my followup for why solution 3 is better but not implementable in the current state of affairs. > If SCTP is stream based at all levels, why does this have anything to do > with a discussion on how to support datagrams-based IO (again: we > _could_ implemented datagram-based IO on top of a stream abstraction, > but why would we want to do that? what value does it add over a > dedicated datagram abstraction?). It all started when I asserted that SCTP, though message-based, could not be implemented on top of the TIP, assertion that was briefly challenged and for which I provided thorough explaination. >> All four solutions provide unified models for both SCTP and UDP. If we >> see UDP as a very restricted subset of SCTP when it comes to I/O, this >> means that each datagram is a separate channel. > Yes, _if_ we see UDP that way. But we don't. We don't see much use in > exposing each datagram as a separate channel, and if we did then we > could turn a datagram into a channel very easily using [chan create]. > > Given the [datagram] API I proposed to Colin it would be quite trivial > to implement a command [datagram channelListener callback protocol ?opt > val ...?] that does a [chan create] for each received message and calls > the $callback with similar params to [socket -listen]'s callback. Yes but it's too heavy. The whole idea of datagrams/messages as streams is the consequence of Tcl channel's lack of message boundaries/end of record support. I'm not saying that datagram support should be implemented that way, just that the proposed model is not transposable to other message-based protocols. I'm just saying that, should we support message-based protocol in a generic way, this would require a stream-based interface. >> Regarding UDP, a low level approch would need something similar to >> solution 1 (bar the SCTP-specific stuff): one single channel, metadata >> at each I/O operation, no callback. That's more or less what TclUDP >> does. A high level, string-based approach gives something similar to TIP >> #409, but is not transposable to SCTP because of the streams vs. strings >> stuff. Solution 4 is a high level, channel-based approach. > Again, [chan create], or just implement SCTP as a channel as you > proposed in scenario #4. With the UDP implementation proposed by TIP > #409 you could implement SCTP tunnelling over UDP (per > http://www.ietf.org/proceedings/48/I-D/sigtran-sctptunnel-00.txt) using > [datagram] and [chan create]. You could do a proper implementation of > SCTP over [datagram] once raw sockets are supported. Well... First of all, SCTP over UDP is impractical, simply because it was an interim solution for testing purpose at a time where SCTP wasn't widely supported (notably routers). AFAIK nobody uses that anymore. As for implementing SCTP over raw socket, this is a joke, right? Unless you're really suggesting me to develop a whole protocol stack in Tcl when software and hardware support exists. |