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

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.

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()?

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 ***

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

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

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/

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 ***

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

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.

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 ***

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...

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...

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

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

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...

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

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/

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