0

Using the code:

Dim client As New System.Net.Sockets.TcpClient()
client.ReceiveTimeout = 250
client.SendTimeout = 250
client.Connect(New System.Net.IPEndPoint(New System.Net.IPAddress({***, ***, ***, ***}), *****))
Assert.IsTrue(client.GetStream.CanTimeout)

Try
    While True
        Dim sent As Integer = client.Client.Send({0})
        System.Threading.Thread.Sleep(100)
        ' Cable is physically disconnected while this loop is active.
    End While
Catch ex As Exception
End Try

It takes 18 seconds for the loop to be aware of a hard disconnection. How could it take so long given the timeout is 250 ms?

djv
  • 15,168
  • 7
  • 48
  • 72
J Collins
  • 2,106
  • 1
  • 23
  • 30
  • Oh man, do not connect to a TcpClient like that, do not setup a try/catch without doing anything in the catch, and certainly do not check for a timeout using a busy loop that uses Sleep. Take a look at this example (which can be ran through a C# to VB converter if needed) that uses begin connect: https://stackoverflow.com/questions/17118632/how-to-set-the-timeout-for-a-tcpclient – David Sep 15 '20 at 15:39
  • The fine manual isn't particularly clear, but implies you need to call `GetStream().Write(...)` and if tcpclient doesn't get confirmation of the number of bytes written to the socket within the timeout an exception is raised.. Note that I wouldn't necessarily expect this to mean the bytes have come out of the other end/experienced an error in transmit that you subsequently rapidly get to know about. Nothing in this world of buffered IO and multiple geographically separate systems could reasonably be guaranteed to always happen within 250ms - you might timeout after 250 and the bytes arrive OK – Caius Jard Sep 15 '20 at 15:53
  • @CaiusJard I understand the two methods are equivalent, but using GetStream().Write() and even following with GetStream().Flush(), does not change the behaviour. – J Collins Sep 15 '20 at 16:01
  • @David I am not interested in a code review, this is a unit test to prove out specific functionality. If your comment materially changes the behaviour I am questioning, please let me know how and I will respond appropriately. – J Collins Sep 15 '20 at 16:03
  • To be honest I wasn't expecting it to change anything; I haven't programmed it but just going off the documentation's inferences it reads that by setting a timeout you're giving the underlying socket 250ms to promise it has sent a single byte - and it will probably always manage to promise it has sent such a small amount of data in quarter of a second.. But what the socket thinks of as "sent" and what you think of as "sent" are probably a) quite different and b) unrelated to your complaint that you're getting notified of connection lost 18 seconds later – Caius Jard Sep 15 '20 at 16:06
  • @CaiusJard That's right. I know that the system can comfortably buffer a byte at a time inside a quarter of a second, but that is not the question I am trying to ask the system. – J Collins Sep 15 '20 at 16:10
  • I get what you're wanting to know - you want to know within a quarter of a second whether your socket has disconnected or not. My guess is that you are indeed being told as soon as is reasonably practical that the socket has been disconnected (it's not in a networks interest to remember connections longer than necessary) but this is unrelated to a send timeout – Caius Jard Sep 15 '20 at 16:14
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/221522/discussion-between-j-collins-and-caius-jard). – J Collins Sep 15 '20 at 16:15
  • 1
    @JCollins - Go to the linked SO thread and you'll see how to set this up asynchronously to properly handle connection timeouts. – David Sep 15 '20 at 16:35
  • @David, I've had a good peruse of that thread, there are no less than 8 different answers. The accepted answer is regarding a timeout on making a connection, not sending data. The asynchronicity is used to facilitate custom timeouts on connection which, while interesting, doesn't answer my question. I want to know in the shortest time possible after the disconnection of a previously good connection has occurred, that a disconnection has occurred. How does your asynchronicity answer this question? – J Collins Sep 15 '20 at 17:32

0 Answers0