By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,549 Members | 1,717 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,549 IT Pros & Developers. It's quick & easy.

Another socket programming question

P: n/a
Thanks to everyone that responded to my previous Socket Programming question. Now I have run into some behavior that I don't quite understand.

Programming environment. VS.NET 2003, C#, Windows XP.

About the architecture:
I have a socket server dll that contains a class that handles connections for a given local ipaddress and port. This class(server) can be started or stopped by calls to the appropriate functions. The server class has a custom developed collection class that is used to track all sockets that connect to the server(server functionality) as well as any sockets that the server must create to communicate with peers(client functionality). The collection class contains a custom developed socketTrackerItem class that contains a reference to the socket as well as two custom developed classes. One for listening that can be started and stopped and one for sending data over the socket. All socket handling is Async with ManualResetEvents handling synchronization where appropriate.

Usage scenario:
The usage in which I am have a problem is this. A peer lets say Peer A connects to another peer, Peer B, on a specific IPAddress and Port to send a one time only information packet. So Peer B's server class has been started and is listening for incoming connection attempts. Peer A creates a new socket to Peer B because one does not already exist and connects. Peer B is setting waiting for a connection. Peer B get the connection request from Peer A which is handled by BeginConnectCallback. This callback checks to see if Peer A should be allowed to connect, i.e. not on block list, and if it is allowed creates a new SocketTrackerItem, adds a new SocketListener and SocketSender to the SocketTrackerItem, starts the SocketListener to listen for any data sent on the connected socket, then adds the SocketTrackerItem to the collection based upon connected socket's RemoteEndPoint hash. The ConnectDone manual reset event is fired and the server goes back to listening for connection attempts. Peer A then sends a chunk of data to Peer B which is in the listening mode. Peer B is waiting in a loop that runs as long as the SocketListener IsRunning property is true with a call to BeginReceive and a ReceiveDone.WaitOne() call after the call. The ReceiveCallback gets called, reads the bytes, checks how many bytes that the EndReceive function returned, then set ReceiveDone.Set(). Peer A disconnects with calls to Shutdown(SocketShutdown.Both) then calls close on the socket. I need to mention that when Peer B accepted the connection it done a SetSocketOption for KeepAlive and DontLinger options so the socket should be notified very quickly after a socket disconnect.

Observed Behavior:
Once Peer A disconnects Peer B socket that it is listening on ConnectedValue is never set to false. Also a SocketError is never thrown in the BeginReceive or BeginReceiveCallback functions to indicate that Peer A has disconnected. Also on PeerB, which is in a BeginReceive -> BeginReceiveCallback loop listening for data, the BeginReceiveCallback functions fires all the time with 0 bytes read which the callback then does a ReceiveDone.Set() (manualResetEvent) that the BeginRecieve function is waiting on before it issues another call to BeginReceive on the socket. From my understanding the socket doesn't call the ReceiveCallback until there is data in the socket buffer that needs to be read. Is this the correct behavior. If so, I can write code to handle it but it wasn't what I was expecting. So I have two behaviors that I didn't expect. 1.) The BeginReceiveCallback is called even if there is no data to read and 2.) In the BeginReceive and BeginReceiveCallback function of my listener no SocketError is thrown to indicate that a connected socket disconnected. Are these behaviors correct?

Thanks for listening to my long winded question but I wanted you to have all the facts to understand the situation. Thank you for any help that you may be able to supply.

John
Nov 16 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
When you get zero bytes from the EndReceive method it means the socket was
closed.

From the MSDN docs on Socket.EndReceive

"If the remote host shuts down the Socket connection with the Shutdown
method, and all available data has been received, the EndReceive method will
complete immediately and return zero bytes."

That should be of some help
Tom

"John Sheppard" <Jo**********@discussions.microsoft.com> wrote in message
news:54**********************************@microsof t.com...
Thanks to everyone that responded to my previous Socket Programming question. Now I have run into some behavior that I don't quite understand.
Programming environment. VS.NET 2003, C#, Windows XP.

About the architecture:
I have a socket server dll that contains a class that handles connections for a given local ipaddress and port. This class(server) can be started or
stopped by calls to the appropriate functions. The server class has a
custom developed collection class that is used to track all sockets that
connect to the server(server functionality) as well as any sockets that the
server must create to communicate with peers(client functionality). The
collection class contains a custom developed socketTrackerItem class that
contains a reference to the socket as well as two custom developed classes.
One for listening that can be started and stopped and one for sending data
over the socket. All socket handling is Async with ManualResetEvents
handling synchronization where appropriate.
Usage scenario:
The usage in which I am have a problem is this. A peer lets say Peer A connects to another peer, Peer B, on a specific IPAddress and Port to send a
one time only information packet. So Peer B's server class has been started
and is listening for incoming connection attempts. Peer A creates a new
socket to Peer B because one does not already exist and connects. Peer B is
setting waiting for a connection. Peer B get the connection request from
Peer A which is handled by BeginConnectCallback. This callback checks to
see if Peer A should be allowed to connect, i.e. not on block list, and if
it is allowed creates a new SocketTrackerItem, adds a new SocketListener and
SocketSender to the SocketTrackerItem, starts the SocketListener to listen
for any data sent on the connected socket, then adds the SocketTrackerItem
to the collection based upon connected socket's RemoteEndPoint hash. The
ConnectDone manual reset event is fired and the server goes back to
listening for connection attempts. Peer A then sends a chunk of data to
Peer B which is in the listening mode. Peer B is waiting in a loop that
runs as long as the SocketListener IsRunning property is true with a call to
BeginReceive and a ReceiveDone.WaitOne() call after the call. The
ReceiveCallback gets called, reads the bytes, checks how many bytes that the
EndReceive function returned, then set ReceiveDone.Set(). Peer A
disconnects with calls to Shutdown(SocketShutdown.Both) then calls close on
the socket. I need to mention that when Peer B accepted the connection it
done a SetSocketOption for KeepAlive and DontLinger options so the socket
should be notified very quickly after a socket disconnect.
Observed Behavior:
Once Peer A disconnects Peer B socket that it is listening on ConnectedValue is never set to false. Also a SocketError is never thrown in
the BeginReceive or BeginReceiveCallback functions to indicate that Peer A
has disconnected. Also on PeerB, which is in a BeginReceive ->
BeginReceiveCallback loop listening for data, the BeginReceiveCallback
functions fires all the time with 0 bytes read which the callback then does
a ReceiveDone.Set() (manualResetEvent) that the BeginRecieve function is
waiting on before it issues another call to BeginReceive on the socket.
From my understanding the socket doesn't call the ReceiveCallback until
there is data in the socket buffer that needs to be read. Is this the
correct behavior. If so, I can write code to handle it but it wasn't what I
was expecting. So I have two behaviors that I didn't expect. 1.) The
BeginReceiveCallback is called even if there is no data to read and 2.) In
the BeginReceive and BeginReceiveCallback function of my listener no
SocketError is thrown to indicate that a connected socket disconnected. Are
these behaviors correct?
Thanks for listening to my long winded question but I wanted you to have all the facts to understand the situation. Thank you for any help that you
may be able to supply.
John

Nov 16 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.