[EMAIL PROTECTED] wrote:
It looks like the .Net Sockets class has some built in
connection-management code even for UDP. I received the following
exception last night:
System.Net.Sockets.SocketException: An existing connection was
forcibly closed by the remote host
at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult,
EndPoint& endPoint)
at libsecondlife.Circuit.OnReceivedData(IAsyncResult result)
After doing a bit of research I found that this will occur on UDP in
the following circumstances: The server is disconnected from the
client (perhaps due to a server crash). The client tries to send a
packet to the server. An ICMP “port unreachable” error is received by
the client (not seen by the application layer). The next time the
client tries to send another packet to the server, the above exception
is thrown, indicating the remote host was unable to deliver a
previously sent UDP datagram and responded with a “port unreachable”
ICMP packet. At this point the socket must be closed as it is no
longer usable.
Is there any work underway to handle disconnections (as discussed
previously) or should I take a look at this? I don’t have time
immediately, but I could take a look at a general remote disconnection
event mechanism in a few days if nobody else is working on it.
Thanks,
Sam
I'm thinking it will be all you setting up the disconnection stuff,
unless someone who is waiting on full daemon code goes on a crazy coding
spree. Setup a delegate for DisconnectedEvent, and take a look at how
the other delegates are handled (firing them is wrapped inside an if (!=
null) { } block). It should also be fired after Logout() is called. Also
we'll need an internal function to handle both logging out and random
disconnections that will reset everything in SecondLife, so if you
disconnect and reconnect the class isn't full of stale data.
John
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
