Calling close on a socket with a broken connection throws an exception (unknown socket id)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Purposefully break a connection
2. Call close on the socket

What is the expected output? What do you see instead?
I would assume as long as the socket object is non-null, that calling Close on 
it should be a safe operation.

What version of the product are you using? On what operating system?
0.9.0.0, running on Windows 2008 R2 SP1

Please provide any additional information below.
Right now, I am having to wrap my Close in a try/catch, ignoring any 
Udt.SocketException that happen. Is there a different, recommended way to do 
this?

Original issue reported on code.google.com by brian.cu...@gmail.com on 14 Nov 2013 at 6:51

[GoogleCodeExporter]

What do you mean by purposefully break a connection?

Original comment by cthomas7...@gmail.com on 15 Nov 2013 at 12:49

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Haha, well I guess that was a gross oversimplification of something that is not 
very easy to do :) In my case, I had a reliable way to break my socket. I 
looked up the error code on the UDT error code page.

ECONNLOST   2001    connection was broken.

So I mean broken as in whatever they are defining broken as there. Then when 
attempting to close the connection (from the listen/accept side of the socket 
in case that matters), I would get the invalid socket id exception.

Adding the try/catch around my close allowed me to close it in all cases.

Original comment by brian.cu...@gmail.com on 15 Nov 2013 at 12:57

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Invalid socket id errors are now ignore on close with v0.10.0.0. The socket id 
should never be invalid. I guess there are cases where the native udt lib 
invalidates the socket id.

Original comment by cthomas7...@gmail.com on 2 Dec 2013 at 4:03

• Changed state: Fixed
• Added labels: 0.10.0.0
• Removed labels: ****

[GoogleCodeExporter]

excellent, thank you! :)

Original comment by brian.cu...@gmail.com on 2 Dec 2013 at 8:28

• Added labels: ****
• Removed labels: ****