Re: [dccp] status of available DCCP implementations?

[acme at ghostprotocols.net (Arnaldo Carvalho de Melo)]

Em Tue, Aug 02, 2005 at 09:10:49AM +1200, Ian McDonald escreveu:
> > 
> > I see no problems for you to chat on this list. DCCP is at a point 
> > where implementation and experimental results are very useful!
> > 
> 
> My 2c on this is that I see this list as discussing general DCCP
> implementation and comments where the other list (dccp at vger.kernel.org)

To subscribe to this list just send a message to majordomo at vger.kernel.org
with "subscribe dccp" on the body.

As for the status of the linux stack:

1. Joacim is doing much needed interop tests with his FreeBSD
   implementation, this has already resulted in bug fixes in the linux
   DCCP stack, kudos to Joacim!

2. See Ian's postings to this list to see what he is up to, keep it up Ian!

3. I'm working on merging the refactorings done on the Linux kernel TCP/IP
   stack that makes a _ton_ of code to be shared with DCCP, David Miller,
   the Linux networking maintainer has merged all the submitted changesets
   so far in his net-2.6.14.git tree, that will be merged with Linus when
   2.6.14 starts, you can see the code look at my changesets in:

http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.14.git;a=summary

   And this one has the patches I'll submit to Dave as soon as he recovers
from his trip to UKUUG:

http://www.kernel.org/git/?p=linux/kernel/git/acme/net-2.6.14.git;a=summary

   Basically the work in this tree is on completely generalising the TCP
hashtables code, that will ultimately yield sock ID lookups functions
shared by any INET transport level protocol, that can use it directly or
extend it if needed.

   After this I'll generalise the TCP TIMEWAIT code as I did for the syn
sockets, creating a "class" hierarchy that will allow us to share most of
this code with DCCP and other INET transport protocols.

   And no, all these generalisations will not hurt the TCP code at all, in
some cases it improves the performance/memory footprint, I, for instance,
expect optimizations to the TCPv4 code to be resulted with the TIMEWAIT
upcoming refactoring, as as of now the tcp_tw_bucket structure used to
represent a socket in the TIMEWAIT state includes both IPv6 and IPv4
address fields for all TCP IPv4 sockets, that will go away.

- Arnaldo