Asynchronous TCP server -- Misc. questions

[Mochuelo]

Hi,

I'm working with an asynchronous TCP server. I have a few questions
that may seem silly, but I can't get to understand all this.

Let's say that BeginAccept will cause the AcceptCallback method being
executed, and that BeginReceive will cause the ReadCallback method
being execute. I have played a little bit with them, it looks like the
AcceptCallback method gets executed right when a (local or remote)
client requests to connect to this server. I believe that when the
server executes the EndAccept method, it is accepting the connection.
My first silly question is: Why would the server want to reject a
specific connection request, if the Listen method has already
specified in advance the maximum number of simultaneous connections I
want to allow? Could anyone give me an example of a criterium under
which I could want to reject a connection request, assuming the max
number of connections has NOT been reached yet?

Can I know the IP of the client, before accepting the connection
request?

Another question is: The help for BeginAccept says, among other
things:

"Your callback method should implement the EndAccept method. When
your application calls BeginAccept, the system uses a separate thread
to execute the specified callback method and blocks on EndAccept until
a pending connection is retrieved."

I don't understand why it says "blocks". ReadCallback is executed
right at the beginning of every chunk received, or at the end? If it
is executed at the beginning, I could understand the "block". It would
block until the end of the chunk is reached, when all the chunk data
is finally present in the receive buffer. If ReadCallback is executed
at the end of every chunk received, I don't understand the word
"block". Could someone help me understand this?

Thank you very much.

 

[Mochuelo]

I forgot another question.

Each time that the client closes the connection, my ReadCallback gets
executed, but EndReceive returns 0 bytes.

If ReadCallback gets executed, and EndReceive returns 0 bytes, can I
always conclude that the client has closed the connection?

In other words, can I reliably use this symptom to detect (from the
server point of view) that the connnection with a client has been
lost?

Thanks.

 

[Sean Hederman]

Hi,

I'm working with an asynchronous TCP server. I have a few questions
that may seem silly, but I can't get to understand all this.

Let's say that BeginAccept will cause the AcceptCallback method being
executed, and that BeginReceive will cause the ReadCallback method
being execute. I have played a little bit with them, it looks like the
AcceptCallback method gets executed right when a (local or remote)
client requests to connect to this server. I believe that when the
server executes the EndAccept method, it is accepting the connection.

Sort of, it's completing the Begin...End started by BeginAccept.

My first silly question is: Why would the server want to reject a
specific connection request, if the Listen method has already
specified in advance the maximum number of simultaneous connections I
want to allow? Could anyone give me an example of a criterium under
which I could want to reject a connection request, assuming the max
number of connections has NOT been reached yet?

You might want to reject connections based on all sorts of criteria, eg.
server load.

Can I know the IP of the client, before accepting the connection
request?

No, the socket is only available from EndAccept.

Another question is: The help for BeginAccept says, among other
things:

"Your callback method should implement the EndAccept method. When
your application calls BeginAccept, the system uses a separate thread
to execute the specified callback method and blocks on EndAccept until
a pending connection is retrieved."

I don't understand why it says "blocks". ReadCallback is executed
right at the beginning of every chunk received, or at the end? If it
is executed at the beginning, I could understand the "block". It would
block until the end of the chunk is reached, when all the chunk data
is finally present in the receive buffer. If ReadCallback is executed
at the end of every chunk received, I don't understand the word
"block". Could someone help me understand this?

"blocks on EndAccept", not ReadCallback. If you don't specify a ReadCallback
(i.e. leave it null), then your code would have to call EndAccept manually.
Once EndAccept is called, assuming it's not finished, your thread will block
until such time as it is.

 

[Mochuelo]

Sort of, it's completing the Begin...End started by BeginAccept.

Yes. But, in that sentence, I was thinking from the client point of
view. The client doesn't see its connection request as being accepted
until the server executes exactly which instruction? I believe it is
EndAccept.

You might want to reject connections based on all sorts of criteria, eg.
server load.

Ok, that could be a criterium.

The way to reject a connection is by not calling EndAccept, or by
calling it, and then closing the connection?

No, the socket is only available from EndAccept.

So, the only way to keep away from certain "banned" client IPs would
be to first accept, and then close the connection, I guess.

"blocks on EndAccept", not ReadCallback. If you don't specify a ReadCallback
(i.e. leave it null), then your code would have to call EndAccept manually.
Once EndAccept is called, assuming it's not finished, your thread will block
until such time as it is.

Understood. That makes sense.

Again, thanks.

 

[Sean Hederman]

[Snip]
The way to reject a connection is by not calling EndAccept, or by
calling it, and then closing the connection?

I'd prefer to call EndAccept and then close the connection. My worry would
be that keeping the listener open would result in blocking the socket to
other connections (since nothing will be waiting for them). In addition I'm
pretty certain that you can't call BeginReceive followed by BeginReceive,
you have to call EndReceive between them.

So, the only way to keep away from certain "banned" client IPs would
be to first accept, and then close the connection, I guess.

Yep.