Re: RFC1122 urgent data conformance question

[[e-mail]]

> 
> 
> > 
> > Question: If the TCP receives an urgent input and queues the urgent input with
> > an indication that it is urgent on the application's input queue, does this, in
> > your opinion, conform to the above excerpt from RFC1122?
> > 
> 
> In my opinion, no.  The Urgent interface to the application layer is
> intended to solve the problem of the application NOT reading its input,
> eg because it is looping or otherwise mis-behaving.  Urgent is intended
> to activate an asynchronous thread (in practice, in the Telnet under-
> belly of the application layer) to unstick things.

From my understanding I thought that the asynchronous notification was needed
because in the standard UNIX environment there is only one activity/process per
connection. This creates the problem where the activity/process can be 
looping, or just doing output without checking to see if there is input to
process. Since in the case that I described there is an activity dedicated to
processing input, this problem doesn't exist. Therefore I would think that
in my case, the asynchronous notification would be not applicable instead of
a non-conformance. How does that sound?


> 
> From your description of the host operating system environment, I gather
> that this is not a general-purpose host, which is the intended domain of
> RFC-1122. 

No, this is not a special purpose host, it is the standard Unisys 2200      
mainframe. We have been doing things this way for over 10 years. The 2200 
mainframe has been a multiprocessor machine for approx 20 years.
It is possible for a general purpose host to be something other than a single
processor UNIX box. :-)

>                 (But what happens if the application DOES go into a
> loop and stop reading its input?)

I would assume that it would be the same as if the asynchronous thread did the
same thing. You always have this possibility.

Since you cc'd the other WG, I pulled it out of the header and am sending this
there also. Thanks for your reply.

Kurt Matthys
Unisys Corp
[e-mail]