Subject: [dcp] A new DCP Implementation

From: "Patrick R. McManus" <[email-masked]>
Date: Sat, 18 May 2002 22:59:16 -0400

Folks,

I've been working on a DCCP implementation for research
purposes. Judging by the "release early and often" standard it is time
to share what I've got. (Judging by any other sane standard of quality
control it's far too early ;).

The implementation is for Linux - it runs at the kernel level directly
on top of IP. My patches are against version 2.4.18 - the patches are
licensed as GPL code.

http://www.ducksong.com:81/dccp/

There is a whole litany of things known to be done still - as well as
I'm sure many problems with the existing code. That notwithstanding,
what is there is pretty functional - socket(), bind(), accept(),
connect(), send(), recv(), and close() work and push data around the
network. Certainly there is enough for people to play with a little,
and maybe even (hopefully?) post patches against.

The code definitely takes a correctness before optimization approach -
and there is no doubt work to be done on the correctness front before
even pondering optimization. Be forewarned.

A partial list of things I have no support for (consider this a
 partial TODO list) ECN, Move Types, Poll(), buffered sends (send will
 block if congestion control dictates), variable recv buffer sizes,
 ccid 3, service names other than 0, sending/recving data on
 handshake, using timestamps for rtt samples.

There's also a security problem or two (I let you grow the ackvector
infinitely for example - bad idea in kernel space.)

but still, its a good start. Feedback is welcome.

-Patrick

_______________________________________________
dcp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcp

---

From: "Patrick R. McManus" <[email-masked]>
Date: Thu, 30 May 2002 21:08:27 -0400

[pat atducksong: Sat, May 18, 2002 at 10:59:16PM -0400]

> control it's far too early ;).

It has been a little while since I sent an update, so I thought I'd do
that. I haven't been able to invest a whole lot of time in DCCP, but
there has been some significant progress over the last 10 days or so:

* listen()
* poll() [and there was much rejoicing..]
* service names [1]
* payload allowed on both request and response [2]
* lookaside buffer cache allocations
* numerous crashing bugs
* a memory leak or two
* hashes on the lookup lists

The patches are still against linux's 2.4.18 vanilla kernel and are
always linked off of:  http://www.ducksong.com:81/dccp/

I want to mention the API I used for a couple of features, as it does
impact user space. Probably not the kind of thing apropos for the
specification, but it would be nice if different implementations had
complimentary apis - these aren't set in stone (heck the whole thing
is just a research implementation) so please comment.

[1] service names - I introduced a new structure
struct sockaddr_dcp
{
  struct sockaddr_in in;
  unsigned int service;
};

which may be passed to bind() or connect() in lieu of the more
traditional sockaddr_in. Its completely compatible with a ported UDP
ap that uses sockaddr_in though, the stack just assumes service name
of 0 in that case.

[2] handshake payloads.

Initially, the server needs a way to identify whether or not it should
accept data attached to a request or if it should answer with
option=discard (option 1).. if a client gets the discard option on the
response packet it will resend the data on with its ack. The server's
socket can be told to allow/disallow request data via a setsockopt

     setsockopt (s, SOL_DCCP, SO_ALLOW_HANDSHAKE_DATA, (void *)  &y, sizeof (int)));

similarly, setsockopt is used to "preload" data before calling
connect() or accept()..

     setsockopt (s, SOL_DCCP, SO_HANDSHAKE_DATA, (void *) buf, 225);

the data on a bound socket will apply to every accept() done off of
it.. though that data can be modified/canceled by subsequent
setsockopt() calls.

no actual data is returned by the accept() or connect() calls even if
the other side has sent some on the handshake - its just put into the
buffers for the next recv().

-P