Transport protocols and bulk file transfer

[Steven Senger <>]

I've been thinking about API issues. If we have time today I would like 
to discuss the questions below.

Since the primary use of the protocol will be stream transport of bulk 
data I'm assuming we will have the following socket methods.

        - bind, listen, accept, connect, close
        - send/recv using memory buffers with blocking/non-blocking behavior
          determined by sockopt or by separate function calls
        - sendfile/recvfile using file descriptor
        - select

Do we want "overlapped i/o" like UDT? In UDT this is implemented 
through additional parameters on send/recv and getoverlappedresult().

Do we want something like iovec style variants of send/recv?

What steps can we take to minimize buffer copying?

Do we want sendpkt/recvpkt calls that would respect message boundaries 
determined by the underlying udp packet size? This would fit some of my 
uses.

If we have sendpkt/recvpkt can we also support a mechanism that would 
back off of reliable transport by replacing existing unacknowledged 
packets with new data? I have several interactive situations where it 
is better to respond to temporary increases in loss by not attempting 
retransmission of packets if new data is ready to send. This could be 
controlled through a sockopt. More substantial changes to throughput 
would need to be handled by changing the rate at which the application 
was generating data.

I'm assuming that we will expose protocol performance information 
through something like UDT's perfmon().

In addition we will have

        - socket,
        - getsockopt/setsockopt
        - getpeername, getsockname

Do we want a C API or an object oriented API?

- steve