4

I'm aware of Response.IsClientConnected but in my scenario it has a great lag. Code:

// sample code for sending a dynamic file in chuncks

long bytesSent = 0;

while (continueSending)
   {
      if (!AskReceiverToContinue())
         break;

      if (!Response.IsClientConnected)
         break;

     // Your suggestion goes here... :)

      try
      {
         Response.OutputStream.Write(buffer, 0, buffer.Length);
         bytesSent += buffer.Length;
      }
      Catch
      {  // To my experience, this is more reliable than Response.IsClientConnected
         continueSending = false;
      }
   }

The problem is the actual received bytes by client is very smaller in amount than my bytesSent. It seems when a client gets disconnected my program finds out the situation with a great lag (and continue increasing bytesSent) and this is because ASP.NET tells me the situation (client is disconnected) late.

Is there any reliable method for finding out when a client has been disconnected (real-time) ?

Xaqron
  • 29,931
  • 42
  • 140
  • 205

1 Answers1

1

You are transfering over HTTP, aren't you? If yes, there is no way due to the statelessness of the HTTP protocol. Only thing you have to help you is the timeout, which you are already using.

Femaref
  • 60,705
  • 7
  • 138
  • 176
  • 2
    Yes, I'm using HTTP. As I know, there's a underlying `TCP` connection. Why ASP.NET doesn't update `IsClientConnected` as soon as the `TCP` connection is closed ? Can I access the native handle or something like that ? – Xaqron Feb 20 '11 at 12:29
  • Even if this were possible, it wouldn't change a thing as the TCP connection would only be closed if the client timed out. If the client doesn't tell you that he is gone, you have no chance of seeing it bar a timeout. – Femaref Feb 20 '11 at 12:33
  • Then how rapidshare.com counts the users traffic ? – Xaqron Feb 20 '11 at 12:38
  • 1
    I guess they are estimating it given the users speed over time. – Femaref Feb 20 '11 at 12:42