TCPIP timeout

[Maylar]

I have an Ethernet enabled temperature chamber and I'm using TcpClient and its GetStream methods to access it. Connecting to the device is simply

 TcpClient client = new TcpClient(ip_address, port_no);

If the connection fails it will throw an exception. However, that takes like 10 seconds before it times out. Is there any way I can set the default timeout to maybe 1 second?

TIA

[Axcontrols]

//You could make an async function something like this:-
//

    TcpClient client = new System.Net.Sockets.TcpClient();

    var res = client.BeginConnect(ip_address, port_no, null, null);

     System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
     sw.Start();
     while (sw.ElapsedMilliseconds < 1000)  // 1000ms  = 1 second
     {
        if (client.Connected)
        {
            // Yay. We're connected
            // Kill the stopwatch and return true
            return true;
        }
    }
    // if you get here then you timed out.
    return false;

[jmcilhinney]

//You could make an async function something like this:-
//

    TcpClient client = new System.Net.Sockets.TcpClient();

    var res = client.BeginConnect(ip_address, port_no, null, null);

     System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
     sw.Start();
     while (sw.ElapsedMilliseconds < 1000)  // 1000ms  = 1 second
     {
        if (client.Connected)
        {
            // Yay. We're connected
            // Kill the stopwatch and return true
            return true;
        }
    }
    // if you get here then you timed out.
    return false;

That's not a good idea. That's a "busy wait" and those are pretty much always bad. If you want to poll then at least have some time between, e.g. use a Timer with an Interval of 100.

[Axcontrols]

That's not a good idea. That's a "busy wait" and those are pretty much always bad. If you want to poll then at least have some time between, e.g. use a Timer with an Interval of 100.

In my defense though - The OP had a 10 second block. Now he doesn't. I was just showing the OP an example of using .BeginConnect rather than .Connect It's up to the OP to pad it out with timers or whatever to suit his requirements.

Having said that, TCP blocking is actually very common. Look at what Explorer browsing your local network - if a resource isn't available over IP you just get a spinner sometimes for a LONG time. In most cases an application can't do anything till connected so allowing the user to do something is pretty much pointless.

In my own code I prefer to wait longer that 1 second so do it in a thread showing a spinner, a please wait label and a cancel button. But this isn't a lesson in UI design and threading.

[jmcilhinney]

I'm not talking about blocking. Blocking and busy waiting are very much not the same thing. Blocking is like knocking on a door and then waiting for someone to answer it while busy waiting is like opening the door to see if someone is there to answer it over and over and over again with no stopping in between. There's nothing wrong with blocking, although you don't want a UI to freeze and stop repainting if you can avoid it. Busy waiting is never Ok if there is any alternative, which there pretty much always is.

[Axcontrols]

When I ask a question on VBForums the last thing I want is a fully functional function that I can drop into my app. I'm more than happy with just some ideas and suggestions and I'll do the rest myself. I assume the OP will do the same.

Of course you're right. if the user is happy with a 100ms resolution then he can do another check on the stopwatch and do that.

[jmcilhinney]

When I ask a question on VBForums the last thing I want is a fully functional function that I can drop into my app. I'm more than happy with just some ideas and suggestions and I'll do the rest myself. I assume the OP will do the same.

I've been around long enough to have learned that that is not a safe assumption for a significant number of people. There are a number of people who will tell you that you haven't helped them unless you have provided something that they can copy and paste. That's not to say that the OP is one of those people - I don't know either way - but even if they're not, I'd suggest that it is not a great idea to provide examples that contain genuinely bad code to inexperienced users without explaining which parts they should consider replicating and which should be avoided. For instance, I can't count how many times we've had people ask questions on this site about GDI+ when they're having issues largely because they copied the use of CreateGraphics from a lazily-written example that failed to tell them not to do that in proper code.

[Axcontrols]

We've hijacked the OP's thread for our own discussion.

I can't agree about how much sample code we'd need to give in response to a question. It should be enough to get an OP thinking but not do his work for him.

A proper sample would have a threaded spinner and please wait label and a cancel button. It could also use your timers. We could even have a property indicating what resolution the timer should work at. It's never ending.

If we supply a fully working sample packed with error handling then an OP would just paste it in an not learn anything.

On the other hand, I haven't looked down in to the source code of the client connect but it wouldn't surprise me if, deep down, MS is just polling the connection. I'm not sure there's any IRQ that the function can hook in to. So polling might be the only way. Then it would just depend on whether it uses a periodic timer or a sleep or just polls like crazy.

[Maylar]

You both digress... and neither have answered my question. Though from your responses, I'll assume the answer is, "No, the sockets timeout can't be changed".
If the test chamber is connected to the target machine, the connection succeeds quickly. However, on my development system in my office I have no test chamber and it's annoying to wait for the timeout. There's a "please wait" message for the end user, so I've got this covered.

Thanks anyway.

[Axcontrols]

I guess there was just so many posts that you did not actually see the suggestion to use .BeginConnect instead of .Connect

BeginConnect will solve your problem. The discussion we were having was whether one should then loop polling the Connected property or whether one should use a timer.

I see what jmcihinney means about some OPs needing more code.

@jmcihinney. I stand corrected.