Draft: draft-pauly-taps-arch

Commentary: This is a reworking of the text from Section 4.2 of draft - trammell - taps - post - sockets-03 , intended to help motivate the choice of Message - based APIs with framing for the transport services architecture . The level of detail here seems appropriate for the architecture document , rather than the API . 
 Well written , 
 What 's convenient about the framer ? If I have messages of 100 bytes and the length is what defines my message , what 's the point of requiring me to define a framer function that I give to the system ? I just send , send , send , off go 3 100 - byte messages . Hard to get more convenient than that :) I understand that the hook to a sender - side and receiver - side framer can allow you to offer a library that does framing when needed ; I do n't personally see this as a big win , but okay ... and I understand that forcing apps to use a receiver side de - framer can , in principle , let us do cool things on the receiver side ( accessing messages out of the bytestream ) . But for sending this just seems to be an uncomfortable add - on . I guess I should n't be arguing it as somehow it 's again just syntactical sugar , and I said before that I do n't care too much about syntax here . I get it , for the 100 - byte messages the framer just wo n't do anything , and for sending I have to use Connection . Send(Framer . Frame(Message ) ) instead of Connection . Send(Message ) ... these calls could basically be renamed into SendMessage vs. SendSomethingHuge . I said before that I do n't care too much about these syntactical bits . I guess it 's just that tying " Connection . Send(Message ) " to " we assume your Message is big and terminates a TCP connection " is really counterintuitive to me . 
 ... and I think I answered to in the wrong place :(   
 what ’s convenient about the framer ? In a C based implementation , very little . In a high level language implementation , however , it means I can and have it convert the high - level structured data into the on the wire format automatically , using a reusable library . 
 no , no , that was right . Framers can take an object by reference or value of any type , and turn them into an appropriately framed octet array . Syntactic sugar , yes , and pointless in some languages . But have a look at -- here , you 're pushing down the thing that converts application structures into wire structures into the API , so the API speaks to you in terms of your own structures ( in Go , this is generally called a ; IIRC from  is the terminology there ) . If your application - internal structures are already serialized byte arrays , you 're right , there is zero win here . 
 Framers are still very very useful in C. You can use callbacks , function pointers , etc , to help lay our your data , and doing that in the context of the networking thread improves efficiency ( beyond the simpler API ) . 
 even better , then ! 
 also : so this whole line of argument is extremely perplexing to me , and indicative of some sort of fundamental failure to communicate on this particular point . absolutely nobody is saying that this interface implies " your Message ... terminates a TCP connection " on the sender side . I ca n't see where you 're getting the impression otherwise in the text . ( When receiving , yes , if the receiver has no way to deframe the stream , you get a message that never ends , as a series of partial reads that looks just like a bunch of calls on a stream ; i.e. when it fails , it fails to something that basically works exactly like sockets with callbacks . ) I really suggest we table this whole discussion until London , because we do n't seem to be making much progress in here , and ask you to trust me until then when I say that there is never , ever , ever a situation in which an implementation of this interface that was actually working would ever look at a single message on the sender side " oh , cool , that 's done , guess I 'll send a FIN then ! " , ever , because that would be an incredibly silly thing to do . ( where 's the blink tag in github markdown ? i really need the blink tag for this ) 
 On this : Sorry , there 's a lack of context - I interpreted this out of private emails from Tommy , which seemed to pretty clearly say that , if you just call " send " without providing a framer , you do send a  - and I just found that awkward . But heck ! Clearly we all do n't want silliness to happen and we want a nice clean interface , and clearly we can quickly agree on this in London . So no worries , and see y' all soon !
Paragraph (version B):
While some transports expose a byte stream abstraction, most higher
level protocols impose some structure onto that byte stream.  That
is, the higher level protocol operates in terms of messages, protocol
data units (PDUs), rather than using unstructured sequences of bytes,
with each message being processed in turn.  Protocols are specified
in terms of state machines acting on semantic messages, with parsing
the byte stream into messages being a necessary annoyance, rather
than a semantic concern.  Accordingly, the Transport Services
architecture exposes messages as the primary abstraction.  Protocols
that deal only in byte streams, such as TCP, represent their data in
each direction as a single, long message.  When framing protocols are
placed on top of byte streams, the messages used in the API represent
the framed messages within the stream.
Paragraph (version B):
the ability to manage dependencies between messages, when some
messages may not be delivered due to either packet loss or missing
a deadline, in particular the ability to avoid (re-)sending data
that relies on a previous transmission that was never received.
Paragraph (version B):
All require explicit message boundaries, and application-level
framing of messages, to be effective.  Once a message is passed to
the transport, it can not be cancelled or paused, but prioritization
as well as lifetime and retransmission management will provide the
protocol stack with all needed information to send the messages as
quickly as possible without blocking transmission unnecessarily.  The
transport services architecture facilitates this by handling
messages, with known identity (sequence numbers, in the simple case),
lifetimes, niceness, and antecedents.
Paragraph (version B):
Transport protocols such as SCTP provide a message-oriented API that
has similar features to those we describe.  Other transports, such as
TCP, do not.  To support a message oriented API, while still being
compatible with stream-based transport protocols, implementations of
the transport services architecture should provide APIs for framing
and de-framing messages.  That is, we push message framing down into
the transport services API, allowing applications to send and receive
complete messages.  This is backwards compatible with existing
protocols and APIs, since the wire format of messages does not
change, but gives the protocol stack additional information to allow
it to make better use of modern transport services.