c# sockets & SendTimeout functionaility,

  • Thread starter Thread starter vooose
  • Start date Start date
V

vooose

Consider a class MyTcpClient that : from TcpClient...

MyTcpClient tcpClient = new MyTcpClient();

tcpClient.Client = tcpListener.AcceptSocket();
tcpClient.SendTimeout = 5000; //5 seconds

//now pull the cable out the back of the computer the connection was
just made to

tcpClient.Write(something);


After you pull the cable out and waiting longer than 5 seconds, I don't
get any sort of exception resulting from the above line. I am not sure
if SendTimeout is the property to set for what I am trying to achieve.
The end result I'm after is

'After the network layer sends a packet, if I havent received the TCP
ACK for that packet after 5 seconds, then disconnect'

Not sure if this is possible with TcpClient/Sockets in c#?
 
Maybe the data is not actually sent until the send buffer is full. Have you
traced the sent TCP/IP packets? Have you set the TcpClient.NoDelay property
to true?

On the other hand, TcpClient of the .NET Framework has neither Write not
Send methods, you must use either the stream from TcpClient.GetStream or
TcpClient.Client.Send(), but surely you are doing it correctly or your
MyTcpClient class provide those methods.
--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
 
Thinking about standard tcp. The timeout normally is the time required
to "put the buffer" to the operating system and not necessarily put it
on the wire. Shy of some sort of keep-alive protocol with the other
end, the only choice you might have is to use DLLs that let you get the
line sense to see if the wire is out. Under normal tcp, you should be
able to unplug the wire, go out for a coffee break, come back and plug
it in and pick up where you left off.

/steveA
 
Thanks for your replies. I should clarify that my class that extends
TcpClient does use Client.Send( ) to send data.

Steve, what you are saying is exactly the problem! I dont necesarrily
need to know that the other end unplugged or what-have-you. Should be
something of the sort:

A sends packet to B
A waits for ACK
--Connection broken to B
A has waited now 5 seconds for the ACK and should signal somehow (catch
this and do stuff)
 
vooose said:
Thanks for your replies. I should clarify that my class that extends
TcpClient does use Client.Send( ) to send data.

Steve, what you are saying is exactly the problem! I dont necesarrily
need to know that the other end unplugged or what-have-you. Should be
something of the sort:

A sends packet to B
A waits for ACK
--Connection broken to B
A has waited now 5 seconds for the ACK and should signal somehow (catch
this and do stuff)
Click to expand...

To get this done on one of my apps I used a TimerCallBack and a
Threading.Timer to "ping" between the machines. We wanted to stop the
socket from blocking and holding up the thread that was processing the data,
but not use Async communication. The CallBack looked something like this:

private void PingTimer(Object state)
{
try
{
if(pingActive)
{
if(pingActiveCounter == 5)
{
TimeoutExceeded();
return;
}
pingActiveCounter++;
}
else
{
pingActive =true;
//Code to send/receive ping message via TCP socket / TcpClient
here....
pingActiveCounter = 0;
pingActive = false;
}
}
catch(Exception e)
{
Console.WriteLine(e.ToString());
}
}

pingActiveCounter is an int, pingActive is a bool I set. My timer was
firing every 10 seconds, so after the counter got to 5 (1 minute) without a
successful ping response I knew the socket was blocked and the connection
was shot, so I would call TimeoutExceeded() to close the socket and reset
everything that would be needed in the app and inform the user.

HTH.
 
Back
Top