A problem of CPU occupation

Dec 25, 2010 at 7:19 AM

It will cause a higher CPU occupaion when client deliberately disconnect a socket. Of course, the ClearIdleSession thread can close the disconnected session, but it will take a while. I found a "While" loop make it happen  in the "TerminatorCommandStreamReader.ReadCommand" method and I can add a "sleep(20)" to resolve the problem. Is there any best solution?

Dec 25, 2010 at 11:44 AM

I am not sure why there is no exception threw if the client disconnect the connection when server try to read data from network stream.

In your case, thisRead of below statement is zero?

thisRead = m_Stream.Read(m_ReadBuffer, 0, m_ReadBuffer.Length)


You can try to return null if thisRead == 0 to quit the loop and then the connection will be closed.

I also will verify this issue and try to fix it in SuperSocket. Could you provide some client code about the case that client deliberately disconnect a socket.


Thank you for reporting this issue to me.



Dec 25, 2010 at 12:49 PM

Maybe you can use Telnet to recall the issue:

c:> telnet

o xx  //open connection

//do something or nothing

ctrl+[     //back to telnet console

c   //close connection

then,  the issue will  appear.


Dec 25, 2010 at 1:01 PM
Cool, thank you
I have produced it in my FTP server.
It seems that if the server get the 0 size buffer from network stream we can consider the client has disconnected the connection.
I’ll fix this bug and commit the code change today, and it will be included in SuperSocket 1.3 beta 3.
BTW, I have done some changes to simplified the custom protocol implementation in beta 3. The class TerminatorCommandStreamReader will not exist, some of code the read data from stream will be moved to SyncSocketSession.
Anyway, I’ll commit most of changes of SuperSocket 1.3 beta 3 tonight and release it on one day of next week.
Thank you for your help,
Kerry Jiang
From: [email removed]
Sent: Saturday, December 25, 2010 9:49 PM
To: [email removed]
Subject: Re: A problem of CPU occupation [SuperSocket:239530]

From: keyant

Maybe you can use Telnet to recall the issue:

c:> telnet

o xx //open connection

//do something or nothing

ctrl+[ //back to telnet console

c //close connection

then, the issue will appear.

Dec 26, 2010 at 3:50 AM

Please check out the code of the revision: 61224.

This bug has been fixed in this revision.


Dec 26, 2010 at 3:56 AM

Wow! Good job!