[Sois-tcons] Proposed TCONS API manpage
gregory.menke at gsfc.nasa.gov
gregory.menke at gsfc.nasa.gov
Wed May 19 17:21:36 EDT 2004
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
More information about the Sois-tcons
mailing list