How to refuse Connections ? - Unix

This is a discussion on How to refuse Connections ? - Unix ; I want my code to accept only connections to the max of N.. if any client tries to connect to my code when already there are N connections, then it musst be refused... How do i do it? P.S::: I ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: How to refuse Connections ?

  1. How to refuse Connections ?

    I want my code to accept only connections to the max of N.. if any
    client tries to connect to my code when already there are N
    connections, then it musst be refused... How do i do it?
    P.S::: I can accept the connection then close the socket.. But is
    there any other elegant way?


  2. Re: How to refuse Connections ?

    victor wrote:
    > I want my code to accept only connections to the max of N.. if any
    > client tries to connect to my code when already there are N
    > connections, then it musst be refused... How do i do it?
    > P.S::: I can accept the connection then close the socket.. But is
    > there any other elegant way?
    >


    Don't call accept() if the number of connections are greater than N?

    Bjørn

    --
    In need of an embeddable web server?
    http://www.metasystems.no/products/h...der/index.html

  3. Re: How to refuse Connections ?

    B. Augestad wrote:
    > victor wrote:
    >
    >> I want my code to accept only connections to the max of N.. if any
    >> client tries to connect to my code when already there are N
    >> connections, then it musst be refused... How do i do it?
    >> P.S::: I can accept the connection then close the socket.. But is
    >> there any other elegant way?
    >>

    >
    > Don't call accept() if the number of connections are greater than N?
    >

    Make sure to set the backlog value on listen to incoming connections are
    rejected rather than queued.

    --
    Ian Collins.

  4. Re: How to refuse Connections ?

    On 2 Apr, 08:19, Ian Collins wrote:
    > B. Augestad wrote:
    > > victor wrote:

    >
    > >> I want my code to accept only connections to the max of N.. if any
    > >> client tries to connect to my code when already there are N
    > >> connections, then it musst be refused... How do i do it?
    > >> P.S::: I can accept the connection then close the socket.. But is
    > >> there any other elegant way?

    >
    > > Don't call accept() if the number of connections are greater than N?

    >
    > Make sure to set the backlog value on listen to incoming connections are
    > rejected rather than queued.


    Given N, what would be the corresponding (portable) value of backlog
    for listen()?


  5. Re: How to refuse Connections ?

    In article <1175494381.392337.135230@y80g2000hsf.googlegroups. com>,
    "victor" wrote:

    > I want my code to accept only connections to the max of N.. if any
    > client tries to connect to my code when already there are N
    > connections, then it musst be refused... How do i do it?
    > P.S::: I can accept the connection then close the socket.. But is
    > there any other elegant way?


    I don't think so.

    The suggestions to use the listen() backlog parameter are not very
    portable -- I think some implementations just use it as a "suggestion"
    or round up from it.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  6. Re: How to refuse Connections ?

    At about the time of 4/1/2007 11:13 PM, victor stated the following:
    > I want my code to accept only connections to the max of N.. if any
    > client tries to connect to my code when already there are N
    > connections, then it musst be refused... How do i do it?
    > P.S::: I can accept the connection then close the socket.. But is
    > there any other elegant way?
    >


    Shutdown the socket? See shutdown(2) for more info.


    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep

  7. Re: How to refuse Connections ?

    At about the time of 4/3/2007 8:21 PM, Barry Margolin stated the following:
    > In article <1175494381.392337.135230@y80g2000hsf.googlegroups. com>,
    > "victor" wrote:
    >
    >> I want my code to accept only connections to the max of N.. if any
    >> client tries to connect to my code when already there are N
    >> connections, then it musst be refused... How do i do it?
    >> P.S::: I can accept the connection then close the socket.. But is
    >> there any other elegant way?

    >
    > I don't think so.
    >
    > The suggestions to use the listen() backlog parameter are not very
    > portable -- I think some implementations just use it as a "suggestion"
    > or round up from it.
    >


    I know for a fact that FreeBSD will take whatever number you give for
    listen backlog and add 50% to it.


    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep

  8. Re: How to refuse Connections ?

    On Sun, 01 Apr 2007 23:13:01 -0700, victor wrote:

    > I want my code to accept only connections to the max of N.. if any
    > client tries to connect to my code when already there are N connections,
    > then it musst be refused... How do i do it? P.S::: I can accept the
    > connection then close the socket.. But is there any other elegant way?


    Why must it be refused instantly? IMNSHO the two main things to think
    about when looking to solve this problem are:

    1. What happens if someone keeps opening connections, do you spend a lot
    of time calling accept() + close() ... or do nothing.

    2. What happens if you have the max number of connections open, and one
    of the clients wants to open a new connection before they close an old
    one.

    ....in both cases "do nothing" is the correct approach, again IMO.

    --
    James Antill -- james@and.org
    http://www.and.org/and-httpd/ -- $2,000 security guarantee
    http://www.and.org/vstr/

  9. Re: How to refuse Connections ?

    In article ,
    Daniel Rudy wrote:

    > At about the time of 4/1/2007 11:13 PM, victor stated the following:
    > > I want my code to accept only connections to the max of N.. if any
    > > client tries to connect to my code when already there are N
    > > connections, then it musst be refused... How do i do it?
    > > P.S::: I can accept the connection then close the socket.. But is
    > > there any other elegant way?
    > >

    >
    > Shutdown the socket? See shutdown(2) for more info.


    Does shutdown() really make sense for a listening socket? My man page
    doesn't say what happens in this case, it says it "causes all or part of
    a full-duplex connection on the socket associated with s to be shut
    down." A listening socket has no associated "full-duplex connection".

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  10. Re: How to refuse Connections ?

    At about the time of 4/4/2007 6:34 PM, Barry Margolin stated the following:
    > In article ,
    > Daniel Rudy wrote:
    >
    >> At about the time of 4/1/2007 11:13 PM, victor stated the following:
    >>> I want my code to accept only connections to the max of N.. if any
    >>> client tries to connect to my code when already there are N
    >>> connections, then it musst be refused... How do i do it?
    >>> P.S::: I can accept the connection then close the socket.. But is
    >>> there any other elegant way?
    >>>

    >> Shutdown the socket? See shutdown(2) for more info.

    >
    > Does shutdown() really make sense for a listening socket? My man page
    > doesn't say what happens in this case, it says it "causes all or part of
    > a full-duplex connection on the socket associated with s to be shut
    > down." A listening socket has no associated "full-duplex connection".
    >


    I noticed that the man page is *very* lacking on this system call.
    Basically, when you call shutdown, any data in the socket read or write
    buffers (depending on the how parameter) are discarded. You don't use
    it on the listening socket. You use it on the socket descriptor that
    accept returns.

    int sockfd;
    int connfd;
    struct sockaddr_in sa;
    struct sockaddr_in sc;

    /* code to init a server socket */

    while(1)
    {
    connfd = accept(sockfd, (struct sockaddr *) &sc, sizeof(sc));
    shutdown(connfd, SHUT_RDWR);
    close(connfd);
    }

    I have a book that fully discusses all of this, if you are interested.

    UNIX Network Programming; The Sockets Networking API
    Volume 1; Third Edition
    W. Richard Stevens
    Bill Fenner
    Andrew M. Rudoff
    ISBN 0-13-141155-1

    That book taught me how to do network programming. If you are
    interested in learning it, that's the book to get. There's probably a
    4th or 5th edition by now though.


    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep

  11. Re: How to refuse Connections ?

    On Apr 5, 7:13 am, Daniel Rudy wrote:
    > At about the time of 4/4/2007 6:34 PM, Barry Margolin stated the following:
    >
    > > In article ,
    > > Daniel Rudy wrote:

    >
    > >> At about the time of 4/1/2007 11:13 PM, victor stated the following:
    > >>> I want my code to accept only connections to the max of N.. if any
    > >>> client tries to connect to my code when already there are N
    > >>> connections, then it musst be refused... How do i do it?
    > >>> P.S::: I can accept the connection then close the socket.. But is
    > >>> there any other elegant way?

    >
    > >> Shutdown the socket? See shutdown(2) for more info.

    >
    > > Does shutdown() really make sense for a listening socket? My man page
    > > doesn't say what happens in this case, it says it "causes all or part of
    > > a full-duplex connection on the socket associated with s to be shut
    > > down." A listening socket has no associated "full-duplex connection".

    >
    > I noticed that the man page is *very* lacking on this system call.
    > Basically, when you call shutdown, any data in the socket read or write
    > buffers (depending on the how parameter) are discarded.


    Perhaps more importantly, calling shutdown(SHUT_WR) on a TCP
    connection socket causes FIN to be sent.



  12. Re: How to refuse Connections ?

    In article ,
    Daniel Rudy wrote:

    > At about the time of 4/4/2007 6:34 PM, Barry Margolin stated the following:
    > > In article ,
    > > Daniel Rudy wrote:
    > >
    > >> At about the time of 4/1/2007 11:13 PM, victor stated the following:
    > >>> I want my code to accept only connections to the max of N.. if any
    > >>> client tries to connect to my code when already there are N
    > >>> connections, then it musst be refused... How do i do it?
    > >>> P.S::: I can accept the connection then close the socket.. But is
    > >>> there any other elegant way?
    > >>>
    > >> Shutdown the socket? See shutdown(2) for more info.

    > >
    > > Does shutdown() really make sense for a listening socket? My man page
    > > doesn't say what happens in this case, it says it "causes all or part of
    > > a full-duplex connection on the socket associated with s to be shut
    > > down." A listening socket has no associated "full-duplex connection".
    > >

    >
    > I noticed that the man page is *very* lacking on this system call.
    > Basically, when you call shutdown, any data in the socket read or write
    > buffers (depending on the how parameter) are discarded. You don't use
    > it on the listening socket. You use it on the socket descriptor that
    > accept returns.


    Which makes it irrelevant to this thread, since the question was how to
    prevent the LISTENING socket from completing the 3-way handshake. By
    the time accept() returns, it's too late.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  13. Re: How to refuse Connections ?

    victor wrote:
    > I want my code to accept only connections to the max of N.. if any
    > client tries to connect to my code when already there are N
    > connections, then it musst be refused... How do i do it?
    > P.S::: I can accept the connection then close the socket.. But is
    > there any other elegant way?


    Since even a listen backlog of 0 generally still means at least one
    connection can be queued, if you want the > Nth connection attempts to
    be refused, you need to close the socket associated with the listen
    endpoint. From that point on, until you setup another listen
    endpoint, any connection attempt will result in an immediate RST being
    sent to the remote. The remote will then get a "connection refused"
    sort of error from his connect() call.

    As I think is pointed-out elsewhere in the thread, a plain close()
    call after an accept() would result in a FIN, not an RST. You could
    perhaps misuse (IMO) SO_LINGER to cause an RST, but what the remote
    will see is the connect() completing successfully, and then either a
    "remote closed" (FIN sent) or "remote aborted" (RST sent) the
    connection sort of message on a subsequent socket call.

    rick jones

    Finally, unless you are running on Windows (ulikely given the group
    here, but still...) if you use the "really small listen backlog"
    mechanism, the first M connections past N will have connect() complete
    - as seen above. If though you don't actually call accept(), the >
    Mth connection attempts will be met with silence and their connect()
    calls will return a variation on a "connection attempt timed-out"
    message. Those first M connections will sit there for however long
    the remote client application is willing to let them.

    --
    oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  14. Re: How to refuse Connections ?

    Rick Jones wrote:
    > Since even a listen backlog of 0 generally still means at least one
    > connection can be queued, if you want the > Nth connection attempts to
    > be refused, you need to close the socket associated with the listen
    > endpoint. From that point on, until you setup another listen
    > endpoint, any connection attempt will result in an immediate RST being
    > sent to the remote. The remote will then get a "connection refused"
    > sort of error from his connect() call.


    I am not sure what will happen to the remaining connections queued to
    the listen endpoing when you make the Nth accept() call, and then
    close(listenfd). They might close with a FIN, they might close with
    an RST. There may be chapter and verse somewhere, but I'm not sure
    where to find it.

    rick jones
    --
    portable adj, code that compiles under more than one compiler
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  15. Re: How to refuse Connections ?

    At about the time of 4/5/2007 5:41 PM, Barry Margolin stated the following:
    > In article ,
    > Daniel Rudy wrote:
    >
    >> At about the time of 4/4/2007 6:34 PM, Barry Margolin stated the following:
    >>> In article ,
    >>> Daniel Rudy wrote:
    >>>
    >>>> At about the time of 4/1/2007 11:13 PM, victor stated the following:
    >>>>> I want my code to accept only connections to the max of N.. if any
    >>>>> client tries to connect to my code when already there are N
    >>>>> connections, then it musst be refused... How do i do it?
    >>>>> P.S::: I can accept the connection then close the socket.. But is
    >>>>> there any other elegant way?
    >>>>>
    >>>> Shutdown the socket? See shutdown(2) for more info.
    >>> Does shutdown() really make sense for a listening socket? My man page
    >>> doesn't say what happens in this case, it says it "causes all or part of
    >>> a full-duplex connection on the socket associated with s to be shut
    >>> down." A listening socket has no associated "full-duplex connection".
    >>>

    >> I noticed that the man page is *very* lacking on this system call.
    >> Basically, when you call shutdown, any data in the socket read or write
    >> buffers (depending on the how parameter) are discarded. You don't use
    >> it on the listening socket. You use it on the socket descriptor that
    >> accept returns.

    >
    > Which makes it irrelevant to this thread, since the question was how to
    > prevent the LISTENING socket from completing the 3-way handshake. By
    > the time accept() returns, it's too late.
    >


    I don't think that there is a way in Unix to do that except close the
    listening socket when you have your max connections. There will be a
    performance hit because then he will have to reopen the socket when a
    slot becomes free.

    I think it would be best to accept the connection, send some indication
    about maximum connections, like say "Too many connections", and then
    close the connection, with prejudice.

    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep

  16. Re: How to refuse Connections ?

    On Apr 6, 8:41 am, Daniel Rudy wrote:
    > At about the time of 4/5/2007 5:41 PM, Barry Margolin stated the following:
    >
    >
    >
    > > In article ,
    > > Daniel Rudy wrote:

    >
    > >> At about the time of 4/4/2007 6:34 PM, Barry Margolin stated the following:
    > >>> In article ,
    > >>> Daniel Rudy wrote:

    >
    > >>>> At about the time of 4/1/2007 11:13 PM, victor stated the following:
    > >>>>> I want my code to accept only connections to the max of N.. if any
    > >>>>> client tries to connect to my code when already there are N
    > >>>>> connections, then it musst be refused... How do i do it?
    > >>>>> P.S::: I can accept the connection then close the socket.. But is
    > >>>>> there any other elegant way?

    >
    > >>>> Shutdown the socket? See shutdown(2) for more info.
    > >>> Does shutdown() really make sense for a listening socket? My man page
    > >>> doesn't say what happens in this case, it says it "causes all or part of
    > >>> a full-duplex connection on the socket associated with s to be shut
    > >>> down." A listening socket has no associated "full-duplex connection".

    >
    > >> I noticed that the man page is *very* lacking on this system call.
    > >> Basically, when you call shutdown, any data in the socket read or write
    > >> buffers (depending on the how parameter) are discarded. You don't use
    > >> it on the listening socket. You use it on the socket descriptor that
    > >> accept returns.

    >
    > > Which makes it irrelevant to this thread, since the question was how to
    > > prevent the LISTENING socket from completing the 3-way handshake. By
    > > the time accept() returns, it's too late.

    >
    > I don't think that there is a way in Unix to do that except close the
    > listening socket when you have your max connections. There will be a
    > performance hit because then he will have to reopen the socket when a
    > slot becomes free.
    >
    > I think it would be best to accept the connection, send some indication
    > about maximum connections, like say "Too many connections", and then
    > close the connection, with prejudice.
    >
    > --
    > Daniel Rudy
    >
    > Email address has been base64 encoded to reduce spam
    > Decode email address using b64decode or uudecode -m
    >
    > Why geeks like computers: look chat date touch grep make unzip
    > strip view finger mount fcsk more fcsk yes spray umount sleep


    im very pleased with this answer


  17. Re: How to refuse Connections ?

    Daniel Rudy wrote:
    > I don't think that there is a way in Unix to do that except close
    > the listening socket when you have your max connections. There will
    > be a performance hit because then he will have to reopen the socket
    > when a slot becomes free.


    > I think it would be best to accept the connection, send some
    > indication about maximum connections, like say "Too many
    > connections", and then close the connection, with prejudice.


    If you leave the listen socket open, more or less the following happens:

    TCP SYN arrives
    TCP SYN|ACK sent
    TCP ACK arrives
    possibly a client request arrives
    server app calls accept() which will
    allocate a socket/filedescriptor etc
    server app calls send() to send the "there are too many" message
    server app calls close() which will
    send a RST or
    send FIN, receive FIN or FIN|ACK, send ACK, enter TIME_WAIT
    and
    deallocate the socket/filedescriptor

    That is then at least five or six trips up or down the protocol stack,
    and a socket descriptor allocation and deallocation.

    whereas, if one closes the listen socket what happens is:

    TCP SYN arrives
    TCP RST goes out

    Now, when that Nth connection is close, indeed there will be:

    socket call to create new socket - about the same weight as the
    allocation of a socket by accept()
    bind() call - pretty cheap
    listen() call - pretty cheap

    That is two trips up/down the protocol stack, a socket
    deallocation/allocation (I'll count the close of the listen socket)
    and some cheap socket calls.

    I suspect that closing the listen socket is actually cheaper
    performance wise.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  18. Re: How to refuse Connections ?

    At about the time of 4/6/2007 10:18 AM, Rick Jones stated the following:
    > Daniel Rudy wrote:
    >> I don't think that there is a way in Unix to do that except close
    >> the listening socket when you have your max connections. There will
    >> be a performance hit because then he will have to reopen the socket
    >> when a slot becomes free.

    >
    >> I think it would be best to accept the connection, send some
    >> indication about maximum connections, like say "Too many
    >> connections", and then close the connection, with prejudice.

    >
    > If you leave the listen socket open, more or less the following happens:
    >
    > TCP SYN arrives
    > TCP SYN|ACK sent
    > TCP ACK arrives
    > possibly a client request arrives
    > server app calls accept() which will
    > allocate a socket/filedescriptor etc
    > server app calls send() to send the "there are too many" message
    > server app calls close() which will
    > send a RST or
    > send FIN, receive FIN or FIN|ACK, send ACK, enter TIME_WAIT
    > and
    > deallocate the socket/filedescriptor
    >
    > That is then at least five or six trips up or down the protocol stack,
    > and a socket descriptor allocation and deallocation.
    >
    > whereas, if one closes the listen socket what happens is:
    >
    > TCP SYN arrives
    > TCP RST goes out
    >
    > Now, when that Nth connection is close, indeed there will be:
    >
    > socket call to create new socket - about the same weight as the
    > allocation of a socket by accept()
    > bind() call - pretty cheap
    > listen() call - pretty cheap
    >
    > That is two trips up/down the protocol stack, a socket
    > deallocation/allocation (I'll count the close of the listen socket)
    > and some cheap socket calls.
    >
    > I suspect that closing the listen socket is actually cheaper
    > performance wise.
    >
    > rick jones


    Well, you guys obviously know more about this than I do. Thanks for
    dispelling my misconception. I thought that the bind and listen calls
    were expensive, I guess not.


    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep

  19. Re: How to refuse Connections ?

    On Apr 7, 4:23 am, Daniel Rudy wrote:
    > At about the time of 4/6/2007 10:18 AM, Rick Jones stated the following:
    >
    >
    >
    > > Daniel Rudy wrote:
    > >> I don't think that there is a way in Unix to do that except close
    > >> the listening socket when you have your max connections. There will
    > >> be a performance hit because then he will have to reopen the socket
    > >> when a slot becomes free.

    >
    > >> I think it would be best to accept the connection, send some
    > >> indication about maximum connections, like say "Too many
    > >> connections", and then close the connection, with prejudice.

    >
    > > If you leave the listen socket open, more or less the following happens:

    >
    > > TCP SYN arrives
    > > TCP SYN|ACK sent
    > > TCP ACK arrives
    > > possibly a client request arrives
    > > server app calls accept() which will
    > > allocate a socket/filedescriptor etc
    > > server app calls send() to send the "there are too many" message
    > > server app calls close() which will
    > > send a RST or
    > > send FIN, receive FIN or FIN|ACK, send ACK, enter TIME_WAIT
    > > and
    > > deallocate the socket/filedescriptor

    >
    > > That is then at least five or six trips up or down the protocol stack,
    > > and a socket descriptor allocation and deallocation.

    >
    > > whereas, if one closes the listen socket what happens is:

    >
    > > TCP SYN arrives
    > > TCP RST goes out

    >
    > > Now, when that Nth connection is close, indeed there will be:

    >
    > > socket call to create new socket - about the same weight as the
    > > allocation of a socket by accept()
    > > bind() call - pretty cheap
    > > listen() call - pretty cheap

    >
    > > That is two trips up/down the protocol stack, a socket
    > > deallocation/allocation (I'll count the close of the listen socket)
    > > and some cheap socket calls.

    >
    > > I suspect that closing the listen socket is actually cheaper
    > > performance wise.

    >
    > > rick jones

    >
    > Well, you guys obviously know more about this than I do. Thanks for
    > dispelling my misconception. I thought that the bind and listen calls
    > were expensive, I guess not.


    You might like taking a look at socket/bind benchmark results:
    http://bulk.fefe.de/scalability/


  20. Re: How to refuse Connections ?

    At about the time of 4/7/2007 1:44 AM, Maxim Yegorushkin stated the
    following:
    > On Apr 7, 4:23 am, Daniel Rudy wrote:
    >> Well, you guys obviously know more about this than I do. Thanks for
    >> dispelling my misconception. I thought that the bind and listen calls
    >> were expensive, I guess not.

    >
    > You might like taking a look at socket/bind benchmark results:
    > http://bulk.fefe.de/scalability/
    >


    That was actually quite interesting. I run FreeBSD 6.2 now....But 5 was
    unstable like anyone's business.

    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep

+ Reply to Thread