On Thu, 2002-03-07 at 14:39, Marek Zawadzki wrote:
> Hello,
>
> I've been trying to implement queuing and 'accept' in my protocol for few
> weeks.
> The way 'accept' should work is still not clear for me:
> We have a socket s and we do the following in the server:
> 1. listen(s) -- thus s->sk_state = TCP_LISTEN.
> 2. accept(s) -- put a process into sleep.
> ...
> 3. receiving function gets an 'init' packet and looks for a socket which
> matches packet's destination. The lookup returns s (!).
> 4. I put s on a queue (sk->tp_pinfo.af_tcp.accept_queue) and wake up the
> process (why to put s itself on it's own queue?).
> 5. accept resumes, grabs first socket from the queue (s) and changes its'
> state to TCP_ESTABLISHED and returns it to inet_accpet. (but this is the
> same socket we've been listening on:( ).
> 6. inet_accept grafts s into a new socket(ok), but s is now in
> TCP_ESTABLISHED state, instead of TCP_LISTEN, which ruins next connection.
>
> How to keep the listening state and return the valid socket to
> inet_accept, without messing with inet_accept itself?
> My problem is the socket I am listening on and to which the 'init' packet
> is destinated are the same.
>
Hmmm from the manpage:
[Accept]
extracts the first connection request on the queue of
pending connections, creates a new connected socket with
mostly the same properties as s, and allocates a new file
descriptor for the socket, which is returned. The newly
created socket is no longer in the listening state. The
original socket s is unaffected by this call."
so the sockets are different, if you are worried about the Port on which
are listening, they can be reused, a connection is identified by yje
source and destination IP address and TCP port. so a single host amy
establish many connectons to a single port on another host, so long as
it uses a seperate outgoing port for each one.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
