[Sois-tcons] Proposed TCONS API manpage

[gregory.menke at gsfc.nasa.gov]

Keith Scott writes:
 >  
 > >Keith Scott writes:
 > > > I have been marking up the red book (mainly section 3.6, 
 > >the transport layer
 > > > primitives and API).  Some issues are:
 > > > 
 > > > What to do if the incoming data unit is larger than the 
 > >buffer supplied by
 > > > the application?
 > >
 > >Truncate the buffer.
 > 
 > Um, if I'm an application and want to receive data, and supply a 1k buffer,
 > how do I know the difference between receiving 1k of data and receiving the
 > first 1k of a 2k datagram?

I don't see this issue as much different than it is under udp.  In
this case, if you specify a 1k buffer and get back 1k length, then you
should probably be suspicious.  In other words, supply a rx buffer big
enough for the biggest data unit you expect to receive.

 
 > >
 > >
 > > > Making sure we always give the application the length of 
 > >the various data
 > > > items (particularly payload items).
 > >
 > >The 2 receive function do give the packet length- did I mess that up?
 > >
 > 
 > You probably had it right in your mail; I was going by the red book.  I was
 > also a little confused about the payload items as opposed to the data items
 > in the receive calls.  (The way I am now interpreting things) I think it's
 > probably fair to just give the application the payload pointer back without
 > a length.

Perhaps the "payload" terminology is a poor choice.  The payload
parameter is supposed to be a data item given to TCONS, which is then
passed to the callback.  Its there so the app can optionally provide
some data to the callback to help w/ processing.  The packet data is
always given as its own pointer- void * IIRC.


 > 
 > >
 > > > Do we want to be able to cancel receive requests (or send 
 > >requests before
 > > > the callback is invoked)?
 > >
 > >on a connection-oriented connection, all pending receives should fail
 > >when its closed- corresponding to all sends failing.  connectionless
 > >receives do seem like they will wait forever.  send requests will
 > >always succeed or fail, so I don't think the cancel issue is as
 > >important for them.
 > >
 > >Perhaps we must include the concept of a TCONS session, within which
 > >connections, sends, receives occur.  Then, the session can be closed,
 > >releasing any accumulated state & aborting pending events.
 > 
 > Ah, my mistake.  Presumably asynchronous connectionless applications will
 > call close() (since they will have called make_connectionless_channel()) and
 > that causes future receives to fail.  We better know this, since if an
 > application were to decide to give up without telling us, the memory for its
 > receive buffers could be somewhere else by the time a packet arrives...
 > 

Maybe tcons_close() should affect connectionless sends & receives.  I
had thought it didn't, but I think you're right- it should.  The
subtlety being, with connectionless saps, tcons_close() only affects
pending sends/receives on the local host.  Connection oriented
channels have both ends closed when either end invokes tcons_close().

Gregm