Re: Another socket programming question
From: Arkady Frenkel (arkadyf_at_hotmailxdotx.com)
Date: 07/13/04
- Next message: Dragos Cantemir: "Re: How to programmatically change the interface metric"
- Previous message: Dragos Cantemir: "How to programmatically change the interface metric"
- In reply to: John Sheppard: "Another socket programming question"
- Next in thread: John Sheppard: "Re: Another socket programming question"
- Reply: John Sheppard: "Re: Another socket programming question"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 13 Jul 2004 10:45:31 +0300
When you close one side peer , the second side can fill that only if it do
some operation send/recv , so the listening socket can't know about the
closing of peer socket , but accepted one only if it will do mentioned op .
Arkady
"John Sheppard" <JohnSheppard@discussions.microsoft.com> wrote in message
news:A9A6FDC7-8ACF-476E-B8FC-89CFE23B896D@microsoft.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
- Next message: Dragos Cantemir: "Re: How to programmatically change the interface metric"
- Previous message: Dragos Cantemir: "How to programmatically change the interface metric"
- In reply to: John Sheppard: "Another socket programming question"
- Next in thread: John Sheppard: "Re: Another socket programming question"
- Reply: John Sheppard: "Re: Another socket programming question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
