RE: Urgent as Framing Hint

["Douglas Otis" <dotis@sanlight.net>]

All,

What would the TCP API look like for a Framing TCP protocol?  I am willing
to assume such a framing scheme is possible either by means of a TCP option,
special checksums, urgent pointer redefinitions, or whatever clever concept
makes framing the encapsulation PDUs possible.  The next issue is how do you
employ this framing scheme within existing stacks.

Here is my guess at this topic:

One, modify the Socket Open to include a pointer to the Application Specific
Data Steering & Parsing Routine together with a pointer to the Encapsulation
Descriptors.  This binds the routine to the port.

Two, create a signaling between the TCP stack and this routine so that
buffer can be allocated, data directed, and upon the filling the allocated
buffer, the TCP stack returns the TCP Socket receive.  The parsing is
accomplished by the size of the allocated buffer.  There also needs to be a
means to redefine mid-stream the size of this allocation buffer if
truncation or extension is required or perhaps just a general error signal
relayed to the application via the descriptor.

Three, a definition of the Encapsulation Descriptor list used to communicate
between the Application Specific Data Steering & Parsing Routine and the
frame enhanced application.  Each item within the this descriptor listed
would be updated atomically.  There would be a simple completion flag
signaling completion by the ASDSPR so that the decriptor location can be
reused.  There should also be an error field within the descriptor to
indicate either communication or parsing errors were found to cause the
application to then re-parse the returned data itself.  There may also be an
advantage in including a offset to descriptor within the Socket receive
function return.

I have included a graphical outline of such a scheme.  Any ideas as to how a
Framing TCP stack can be improved?  What details should be added or amended?

Doug

Framed TCP.gif