transport - [transport] comments on transport-api-06.pdf
Subject: Transport protocols and bulk file transfer
List archive
- From: stanislav shalunov <>
- To:
- Subject: [transport] comments on transport-api-06.pdf
- Date: 25 Apr 2005 00:03:23 -0400
Steve,
Here's my set of nits, ahead of Monday's deadline for the first action
item of last teleconference:
0. Title, so that the document can be handed out in Arlington.
1. X_SOCKET probably also contains data structures necessary to
identify the underlying UDP socket and any buffering data
structures. Or is that elsewhere?
2. I'm not quite sure how to implement x_listen() and x_accept(). It
would seem to me that, with a UDP socket underneath, we'd need to
get rid of x_listen() and to only allow one connection per port,
unless we want a user-level demux process looking at the source
address and handing the incoming packet to the right place. The
extra process would mean doubling the number of context switches
and more complex software architecture that requires some kind of a
daemon (presumably forked off in x_listen()?). The straightforward
path would seem to be to get rid of x_listen() and only have
x_accept() work once on a given socket (and return that socket
itself or maybe an integer success indicator). Would that be a
burden from the point of view of application programming?
3. Regardless of resolution of (2), should x_accept() only take one
argument? In Berkeley sockets API, the addr argument for accept()
is a result argument; we could tuck that away inside X_SOCKET
structure.
4. In x_setsockopt(), how does one set reliable datagrams vs
unreliable datagrams behavior? The QTTL option is about partial
reliability. Unreliable service could be set with 0; for reliable
service, a large value could be used. Perhaps the default should
be mentioned here as well. Should the value be u_int32_t (making
it unsigned and fixing the width)? Or perhaps at least unsigned
int? Also, should the value be in microseconds for better
resolution? 2^32 microseconds is more than an hour, which is
plenty.
5. In x_setsockopt() and x_getsockopt(), do we need the
optname/optval/optlen system? Could we just give it a union?
6. In x_socket(), should x_sockstatus() be x_sockerror()?
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
Clothes make the man. Naked people have little or no influence on
society. -- Mark Twain
- [transport] comments on transport-api-06.pdf, stanislav shalunov, 04/25/2005
Archive powered by MHonArc 2.6.16.