asyncore and OOB data

[Douglas Wells]

In article <mailman.597.1184205029.22759.python-list at python.org>,
Steve Holden <steve at holdenweb.com> writes:
> Douglas Wells wrote:
> > 
> > Third, the TCP protocol, which you have selected via the SOCK_STREAM
> > option doesn't support OOB at all, so there's no way that you can
> > even send OOB data in the manner that you are expecting.
> > 
> Wrong. The URGENT pointer indicates that the data begins with 
> out-of-band data. You are correct, however, in stating that the FTP 
> protocol doesn't support or implement out-of-band data transmissions.

Well, first I have to admit that I just looked at the wiki article
on out-of-band (<http://en.wikipedia.org/wiki/Out-of-band>) and
it also makes a statement that TCP urgent data is OOB.  But I
disagree with that interpretation.  So, let me acknowledge that
there are dissenting opinions, and explain my assertion in terms
of the OP's problem of wanting a separate data stream (or at least
that was my interpretation).

First, I fully acknowledge that the concept of TCP's URGENT pointer
itself is out-of-band, but I don't know of any way to associate
data, in the form of an identifiable set of octets, with that
concept.  As supporting evidence I offer the following:

  - There is no way for the sender and the receiver to agree on
    the *start* of an urgent data set.  The end point is clearly
    identified by the urgent pointer, but the start is time dependent
    and is not identified in the TCP communication stream. Thus, the
    sender could not express the concept of sending a particular
    data value, e.g. "This string", to the receiver reliably.

  - If receivers are highly responsive (meaning that the receiver
    is always able to process incoming data without having to
    discard any of it), there will be no difference in the behavior
    of two receivers, one of which properly implements the concept
    of the urgent pointer, and the other of which totally ignores
    the concept of urgency.

  - There appears to be no way to actually read any OOB data from
    a Berkeley socket API. (As I noted my system, at least, returns
    an error in this case.)

> > Let's switch to the positive, however.  What TCP does have is the
> > concept of "urgent" data.  Urgent data is data that the sender
> > believes is so important that the receiver should discard intermediate
> > data, if necessary, in order to process the urgent data -- but the
> > urgent data is sent *in-band*.
> > 
> No, technically the urgent data is out-of-band, isn't it? There is no 
> requirement to ditch the other data in the packet, so urgent data can be 
> interspersed without loss of regular in-band data if required.

This is the same point that I argued above.  I now acknowledge that
some people think of the TCP urgent concept as OOB.  I don't; but
this is a matter of definition and almost certainly not an issue
for coherent argument.

> > In the case of FTP, the concept of urgent data is used to allow
> > the user side to interrupt the data transfer, which it does by
> > sending an ABOR command.  The underlying problem is that the server
> > might be blocked on a receive on the data connection and not
> > listening for commands on the control connection.  So the user
> > side is required to perform some "special action" that includes
> > sending urgent data, which the server can then process specially.
> > This problem arises primarily in systems without either threading
> > or asynchronous I/O APIs.  Your use of asyncore should alleviate
> > this problem.

> > The thing that may be confusing you is that for whatever reason
> > the designers of the Berkeley socket API (which is what you are
> > using when running under POSIX/Linux/MS Windows), chose to use the
> > OOB flags (e.g., MSG_OOB) to indicate the *transmission* of OOB
> > data -- but it's not really OOB data.  In fact, when I attempt to
> > receive using the MSG_OOB flag using the OS interfaces on my system,
> > I get back an error (EINVAL - Invalid argument).  I would expect
> > that asyncore would report this error somehow or other.
> > 
> You can, of course, expect what you like, but experience is the best 
> guide to what will actually happen.

Agreed, but having acknowledged that I had never used asyncore,
I was trying to express the hope that the designers would not
purposely discard a error condition without notifying the user,
particularly for a "reliable" transfer method such as TCP.

>   Steve

 - dmw

-- 
.   Douglas Wells             .  Connection Technologies      .
.   Internet:  -sp9804- -at - contek.com-                     .