OSSP CVS Repository

ossp - ossp-pkg/sa/TODO 1.28
Not logged in
[Honeypot]  [Browse]  [Directory]  [Home]  [Login
[Reports]  [Search]  [Ticket]  [Timeline
  [Raw

ossp-pkg/sa/TODO 1.28

TODO
----

Oh, finally, a performance issue (that probably doesn't matter for
lmtp2nntp):
sa_rc_t sa_read(sa_t *sa, char *cpBuf, size_t nBufReq, size_t *nBufRes)
always flushes the write portion of the outgoing stream, even if the
read is going to be entirely from the local buffer.  This is generally
undesirably behavior, since you can trigger nagle's algorithm if
you're a command/response server with pipelining like LMTP.
Generally, you want to flush the write portion whenever you're about
to block on a read, but not necessarily before.
(Of course, the client-side of a pipelining client is considerably
more complex.)

- on resolving multiple addresses can be returned (especially
  one IPv4 and one IPv6!) and each one has to be tried on
  socket+connect for instance. What to do? See also
  http://www.v6.wide.ad.jp/Presentations/ai3-penang0010-v6programming/mgp00015.html
- support for new getaddrinfo and getnameinfo (IPv6!)
- API function for blocking/non-blocking I/O mode
- more test cases to cover full API
- more documentation to fully describe API

CANDO
-----

o Support for writev(2).

  This can be done by internally switching to always use writev(2),
  providing an emulation for writev(2) ala Pth and by basing the write
  calls always on writev.
  
o Kernel Read/Write Buffer Adjustments.

  BSD Sockets usually provide (see setsockopt(2)):

      SO_SNDBUF          set buffer size for output
      SO_RCVBUF          set buffer size for input
      SO_SNDLOWAT        set minimum count for output
      SO_RCVLOWAT        set minimum count for input

  This would mean that we could also allow the control
  of the kernel buffers via

      SA_BUFFER_KREAD
      SA_BUFFER_KWRITE

  Unfortunately the whole kernel buffer issue is very complex, because
  according to STEVENS there are both minimum and maximum sizes and both
  borders heavily depend on the currently used protocol (TCP or UDP) and
  the MTU of the underlying network, etc. This all together seems like
  opening a can of worms if we provide SA_BUFFER_K{READ,WRITE}.


CVSTrac 2.0.1