The SocketService class doesn't seem to handle disconnects properly. When a client disconnects from server (which uses SocketService) SocketService seems to think there is pending data for the port (SocketPort::Pending is called repeatedly). This behaviour is also present in the example tcpservice.cpp.
I saw a post about this subject dating last summer, but there were no fixes in the followups. Is there a workaround for this, or is the SocketService class supposed to work like this?
btw. using version 1.3.2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There has been some changes recently made to fix race conditions. You may want to check the version in cvs....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-02-19
The cvs version didn't work any better, so I handle disconnects in SocketPort::Pending ..
Another problem that I spotted in SocketService::Run .. in the __CCXX_USE_POLL code where the function calls poll(...). The mutex is left locked, which prohibits things such as SocketPort::Attach etc.. Shouldn't the mutex be unlocked before entering poll(...)? I changed this to be so and everthing worked fine with a single thread.. don't know whether multiple threads would mess this up..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. Sorry to disturb but that message has a special interest for me.
I'm doing a Multithead Socket Socket Server application with CommonC++ libs and , even I'm not using the SocketService & Socketport facilities provided, found the same problem as you in the IsPending for my Sessions. WI have two different conditions in the ::Run() derived method for all my sesions in order to see if the client is sending data or just disconnecting. When it is supposed that the client is sending a disconnecting request the flow enters in the recieving data condition and the application crashes... Maybe because the tcp() stream is not in good state?. Please... could you give me some hints abut it?. Very much appreciated ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-02-24
Hi
Really difficult to know what could be wrong without any specifics. But usually that kind of problems occur when writing to a socket that has disconnected.. i.e. SIGPIPE is raised. You should check whether the socket is usable before trying to read or write to it.
Regarding my handling of disconnects, I just try to read from the socket and if the read returns 0 then disconnect.. not the prettiest way to do this, but is sufficient for my needs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
The SocketService class doesn't seem to handle disconnects properly. When a client disconnects from server (which uses SocketService) SocketService seems to think there is pending data for the port (SocketPort::Pending is called repeatedly). This behaviour is also present in the example tcpservice.cpp.
I saw a post about this subject dating last summer, but there were no fixes in the followups. Is there a workaround for this, or is the SocketService class supposed to work like this?
btw. using version 1.3.2
There has been some changes recently made to fix race conditions. You may want to check the version in cvs....
The cvs version didn't work any better, so I handle disconnects in SocketPort::Pending ..
Another problem that I spotted in SocketService::Run .. in the __CCXX_USE_POLL code where the function calls poll(...). The mutex is left locked, which prohibits things such as SocketPort::Attach etc.. Shouldn't the mutex be unlocked before entering poll(...)? I changed this to be so and everthing worked fine with a single thread.. don't know whether multiple threads would mess this up..
Hello. Sorry to disturb but that message has a special interest for me.
I'm doing a Multithead Socket Socket Server application with CommonC++ libs and , even I'm not using the SocketService & Socketport facilities provided, found the same problem as you in the IsPending for my Sessions. WI have two different conditions in the ::Run() derived method for all my sesions in order to see if the client is sending data or just disconnecting. When it is supposed that the client is sending a disconnecting request the flow enters in the recieving data condition and the application crashes... Maybe because the tcp() stream is not in good state?. Please... could you give me some hints abut it?. Very much appreciated ;-)
Hi
Really difficult to know what could be wrong without any specifics. But usually that kind of problems occur when writing to a socket that has disconnected.. i.e. SIGPIPE is raised. You should check whether the socket is usable before trying to read or write to it.
Regarding my handling of disconnects, I just try to read from the socket and if the read returns 0 then disconnect.. not the prettiest way to do this, but is sufficient for my needs.
Thanks for your comment.
I will try to disable the SIGPIPE signal and make some test in that way.