extend/alter accept() / connect()

From: Michael Skinner (mike_at_nospam-mssnetworks.com)
Date: 04/28/04 

Date: Wed, 28 Apr 2004 22:39:23 +0100

Hi..

I'm considering accept() and connect() in the non-blocking case.

As it stands, a non-blocking call to accept() initiates the 3-way
handshake, but returns immediately with an 'error' of EINPROGRESS. Calls
to read() or write() fail with EAGAIN until the 3-way handshake has
completed.

SYN -->
    <-- SYN ACK
ACK -->

======

I would like to modify the behaviour of connect() so that it returns
immediately, but that the 3 way handshake becomes a 4-way handshake

connect() accept()

SYN -->
          <-- SYN ACK
ACK -->
DATA -->

In such a way that DATA (arbitrary 8 bytes or so) are sent/queued *before*
the socket is marked writable.

==

Put in another way, I wish to modify kernel code so that an arbitrary,
small chunk of data is added ('piggy-backed') to the beginning of every
TCP data stream.

(I realise I could [and have successfully been able to] change
tcp_sendmsg() in such a way as to achieve this piggy back, but the
piggy-back'd data isn't sent until the first time the userspace app calls
write(). I want the data to be sent straight after the connect.)

==

Similarly, I would like to make a modification to accept(), so that it
picks out the DATA that is going to be on the front of the transmission
but before the first read() call.

==

Any ideas?

I've found the place in the code where the SYN-ACK packet is
received/processed, and added an extra tcp_sendmsg() in here, but we fail
with an obscure error in skbuff.c (line 174). {I did remember the
set_fs(KERNEL_DS) call!} But if this were to work, then it would be the
effect I want.

Regards,
Mike

(You can ask why I'm trying to do this, and the short answer is that it's
primarily a bit of a learning exercise with a project in mind rather than
anything that I would immediately expect to be considered as an addition
to the kernel!)