Re: max connections
- From: "guy" <guyvo@xxxxxxxxx>
- Date: Mon, 20 Nov 2006 18:18:32 +0100
Do you stand that even after closing listen() you can do connect() from
peer ?
No that is not the case.
Or you mean that peer succeed to to connect() with 17th socket just
because yet server didn't close listening socket ?
Yes that's it. So I do my 16t accept and after that the listener is closed.
The time in between the last accept en close listener is apparently enough
to have some client connect a 17t. I ran some tests on a small server
program I wrote and saw that clients can connect with only a listener socket
running without accepting them. But if those clients try to send something
on the returned handle they issue with a
10054 error.(reset by peer)
BTW that normal practive to close return by accept() socket not closing
listen because if some one peer shutdown you need to allow new one to
connect.
Suppose in my case the server had opened 16 connection and one client is
closing the connection than the server restarts the listener in allowing
again one (or more if more closed are issued) client to connect. So maybe a
quick solution for my problem could be indeed closing the >16 client after
accepting directly without switching with the listener socket. But what if
the client already sent some bytes instantly just after the open ?
I don't know if there are some frameworks available to deal with maximum
connections of a server. I guess it will because a webserver has to deal
with it too. I don't know if there are some guidelines in the RFCs to handle
this situation following the standards. Anyway I think it's odd when you try
to connect on a winsock listener and don't accept the connection the clients
open() functions returns with no error.
Suppose the server had a backlog=16 you can connect 16 times (without
accept) the 17t returns a connection refused 10061. You have to do an action
on the clients to see that it is reset by the peer. In my opinion it would
be more logical to return an error on the open() if there is no accept in a
reasonable time because that means that the server isn't interesting in
treating connection.
Maybe this behaviour is specified somewhere in a RFC I don't know.
Thanks for taking the time for my problem.
Guy
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> schreef in bericht
news:emP5Z2GDHHA.4060@xxxxxxxxxxxxxxxxxxxxxxx
Do you stand that even after closing listen() you can do connect() from
peer ? Or you mean that peer succeed to to connect() with 17th socket
just because yet server didn't close listening socket ?
BTW that normal practive to close return by accept() socket not closing
listen because if some one peer shutdown you need to allow new one to
connect.
Arkady
"guy" <guyvo@xxxxxxxxx> wrote in message
news:45608ad4$0$30039$ba620e4c@xxxxxxxxxxxxxxxxx
Hi folks,
I have an application running a TCP/IP server programmed in C
(win32/studio6 8 years old). Actually it's not mine written but you know
how it goes if you work in a firm ;-)
Our customers begin now more and more to work in OPEN/CLOSE session. The
server is now limited by 16 connections simultaneously. This is done with
closing the listen() socket when the connections reached 16. The listener
restarts when there is one close performed on the 16 open connections.
It's far from great code I must say!
I explain quickly the situation:
The listener starts and 16 threads are started with each an accept()
call and this in non-blocking mode even to capture an abort event ! This
is of course a bad idea to do so but as mentioned before the code is not
mine. The clients connect to the server and the data is handled with
WriteFile/Readfile overlapped. When the server reached the 16t
connections he closes the listener socket to avoid new incoming
connections. I saw doing tests that when you do that, the client connect
will succeed on the 17t or more. Because if you do a windows connect with
only the listener running at the server site the client will get no error
on the connect call. The reason is of course that the time in between the
closing of the listener and the last accept is enough to have some of
these connections that will gat finally a RST by the server site. But if
you try to send something on a client socket previously reset you get a
10054 back which is normal.
As I pointed it out this code is a real mess. But at the moment I must
find a workaround for this behavior. Rewriting the server code using
WSA... and EX stuff is not an option at the moment.
The question is how can you limit your server connections without having
the client saw that is connected half way but in fact it was one to much
for the server?
I think putting the listener down for that purpose is a bad idea.
Does anyone out there experience the same problems?
And what can I do to solve without rewriting?
If I rewrite what is to best approached to limit a server in accepting
connections?
Tanks
Cheers !
Guy
.
- Follow-Ups:
- Re: max connections
- From: Arkady Frenkel
- Re: max connections
- From: Alexander Nickolov
- Re: max connections
- References:
- max connections
- From: guy
- Re: max connections
- From: Arkady Frenkel
- max connections
- Prev by Date: Why the client can't receive the response from server?
- Next by Date: Re: NAT and keepaliveopen connection over TCP
- Previous by thread: Re: max connections
- Next by thread: Re: max connections
- Index(es):
Relevant Pages
|
