--- TODO 2002/10/26 15:45:32 1.38
+++ TODO 2002/10/26 17:59:30 1.39
@@ -1,79 +1,89 @@
+ _ ___ ____ ____ ____
+ |_|_ _ / _ \/ ___/ ___|| _ \ ___ __ _
+ _|_||_| | | | \___ \___ \| |_) | / __|/ _` |
+ |_||_|_| | |_| |___) |__) | __/ \__ \ (_| |
+ |_|_|_| \___/|____/____/|_| |___/\__,_|
-TODO
-----
+ OSSP sa - Socket Abstraction
-- more test cases to cover full API and especially the client/server usage
-- more documentation to fully describe API
+ TODO
+ ----
-CANDO
------
+ o what about actually written bytes in case of sa_writef?
-o provide "satool", a command line interface to the OSSP sa API.
- Can optionally use readline or libedit, etc.
-
-o support for SSL/TLS via small abstraction layer on top of OpenSSL and
- gnutls libraries.
-
-o Consistently use PF_XXX instead of AF_XXX whenever not directly
- address related things are done in order to even closer conform to POSIX.
-
-o Support for newer DNS Resolving Functions.
-
- In IPv6 land there are usually the newer DNS resolving functions
- getaddrinfo(3) and getnameinfo(3). Perhaps we should support these in
- favor of gethostbyname(3) and gethostbyaddr(3) because the chance is
- higher that they support IPv6 in case we are in IPv6 land.
-
-o DNS Resolving and multiple results.
-
- On DNS resolving name, multiple result addresses can be returned. Either
- because of Round-Robin entries, multi-homed hosts or because of hosts
- talking both IPv4 and IPv6, etc. Each address has to be tried on
- socket+connect. What to do? For some hints see:
- http://www.v6.wide.ad.jp/Presentations/ai3-penang0010-v6programming/mgp00015.html
-
-o Nagle's Algorithm and Flushing of Output Buffers.
-
- The kernel performs Nagle's Algorithm (see RFC 896 and search for "nagle
- algorithm" on www.whatis.com [currently
- http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html]
- on his internal output buffers. Although we flush our user-space output
- buffers only if we really perform a read(2) (and not if the read is going to
- be served entirely from the local buffer) this does not mean that really
- every character the remote has already sent is also already read by us.
- Because the kernel also has a read buffer. Optimal behaviour would be that
- we flush out output buffer only if the read(2) would block. OTOH flushing
- out buffers means performing a write(2) and this again is buffered in the
- kernel, too. So performing an optimal read->write->read->write->... sequence
- is very complex and non-trivial to implement. Especially because even using
- Nagle's Algorithm always is not the right choice (see
- http://www.w3.org/Protocols/HTTP/Performance/Nagle/ for details), especially
- when it comes to pipelining protocols.
-
-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}.
+ o more test cases to cover full API and especially the client/server usage
+
+ o more documentation to fully describe API
+
+ CANDO
+ -----
+
+ o provide "satool", a command line interface to the OSSP sa API.
+ Can optionally use readline or libedit, etc.
+
+ o support for SSL/TLS via small abstraction layer on top of OpenSSL and
+ gnutls libraries.
+
+ o Consistently use PF_XXX instead of AF_XXX whenever not directly
+ address related things are done in order to even closer conform to POSIX.
+
+ o Support for newer DNS Resolving Functions.
+
+ In IPv6 land there are usually the newer DNS resolving functions
+ getaddrinfo(3) and getnameinfo(3). Perhaps we should support these in
+ favor of gethostbyname(3) and gethostbyaddr(3) because the chance is
+ higher that they support IPv6 in case we are in IPv6 land.
+
+ o DNS Resolving and multiple results.
+
+ On DNS resolving name, multiple result addresses can be returned. Either
+ because of Round-Robin entries, multi-homed hosts or because of hosts
+ talking both IPv4 and IPv6, etc. Each address has to be tried on
+ socket+connect. What to do? For some hints see:
+ http://www.v6.wide.ad.jp/Presentations/ai3-penang0010-v6programming/mgp00015.html
+
+ o Nagle's Algorithm and Flushing of Output Buffers.
+
+ The kernel performs Nagle's Algorithm (see RFC 896 and search for "nagle
+ algorithm" on www.whatis.com [currently
+ http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html]
+ on his internal output buffers. Although we flush our user-space output
+ buffers only if we really perform a read(2) (and not if the read is going to
+ be served entirely from the local buffer) this does not mean that really
+ every character the remote has already sent is also already read by us.
+ Because the kernel also has a read buffer. Optimal behaviour would be that
+ we flush out output buffer only if the read(2) would block. OTOH flushing
+ out buffers means performing a write(2) and this again is buffered in the
+ kernel, too. So performing an optimal read->write->read->write->... sequence
+ is very complex and non-trivial to implement. Especially because even using
+ Nagle's Algorithm always is not the right choice (see
+ http://www.w3.org/Protocols/HTTP/Performance/Nagle/ for details), especially
+ when it comes to pipelining protocols.
+
+ 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}.
|
