[Sois-tcons] Proposed TCONS API manpage

[Keith Scott]

>-----Original Message-----
>From: gregory.menke at gsfc.nasa.gov [mailto:gregory.menke at gsfc.nasa.gov] 
>Sent: Wednesday, May 19, 2004 4:02 PM
>To: Keith Scott
>Cc: sois-tcons at mailman.ccsds.org
>Subject: RE: [Sois-tcons] Proposed TCONS API manpage
>
>
>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?

>
>
> > 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.

>
> > 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...



>
>Gregm
>
>