I'm using the TCPStream classes vis TCPSession. In my Run() loop, I've got the typical send/receive logic which works all fine. However the socket never generates an error. Examples:
isConnected() returns true always (even if remove machine drops the socket)
"isConnected" is rather limited in this regard since it only tests the current socket "state", not if it's actually connected. On posix systems, the stream eventually hits an "end of file" if the remote end closes since the recv() (and read) call returns a 0 byte read. I am gathering this actually does not occur on win32?! Also, on Posix, if a dead connection is found, the exception bit of a select is set, and this is what your isPending() test would check for. Finally, you normally need to set KeepAlive to monitor a connection to see if it terminates unexpectidly. Under Posix, this not only results in a error exception bit when a keep-alive socket has lost it's connected peer, but also generates a sigpipe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed my ReadPacket/WritePacket from void to bool functions, and just return good(), which seems to accurately reflect 'is the socket ok' as well the read/write sanity.
I have bigger fish to fry as right now I think there is a super sublte stack or register bug (even in unoptimized code) causing 1 in 20 clients to think there are no outbound packets in its queue (the AtomicCounter member variable has like 50-400 packets, the if() returns 0, stepping through the code shows the 'this' pointer is 200 bytes wrong with the member variable address (blargh). If I could get the linux side of things working socket wise I could run it under electric fence :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked in a new socket.cpp to cvs which may fix the posix problem. I see
two distinct possibilities. First, if you override the "Initial" member, then the code
used to test for connection completion will never execute, and you should call
the test yourself or invoke TCPSession::Initial in your modified initial. Second, it was a
little broken.
What I suspect is happening is that your packet read/write calls are occuring before
the socket has actually connected (it used delayed "connection" in the constructor)
and this is why you get an immediate error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using the TCPStream classes vis TCPSession. In my Run() loop, I've got the typical send/receive logic which works all fine. However the socket never generates an error. Examples:
isConnected() returns true always (even if remove machine drops the socket)
isPending(SOCKET_PENDING_ERROR, 0) return false always (same conditions)
setting setError(true); at the first line of run, no exceptions are ever thrown (also same conditions).
How do I test for these common error conditions? I am using the Win32 side of the libraries for the time being.
"isConnected" is rather limited in this regard since it only tests the current socket "state", not if it's actually connected. On posix systems, the stream eventually hits an "end of file" if the remote end closes since the recv() (and read) call returns a 0 byte read. I am gathering this actually does not occur on win32?! Also, on Posix, if a dead connection is found, the exception bit of a select is set, and this is what your isPending() test would check for. Finally, you normally need to set KeepAlive to monitor a connection to see if it terminates unexpectidly. Under Posix, this not only results in a error exception bit when a keep-alive socket has lost it's connected peer, but also generates a sigpipe.
I changed my ReadPacket/WritePacket from void to bool functions, and just return good(), which seems to accurately reflect 'is the socket ok' as well the read/write sanity.
I have bigger fish to fry as right now I think there is a super sublte stack or register bug (even in unoptimized code) causing 1 in 20 clients to think there are no outbound packets in its queue (the AtomicCounter member variable has like 50-400 packets, the if() returns 0, stepping through the code shows the 'this' pointer is 200 bytes wrong with the member variable address (blargh). If I could get the linux side of things working socket wise I could run it under electric fence :)
I have checked in a new socket.cpp to cvs which may fix the posix problem. I see
two distinct possibilities. First, if you override the "Initial" member, then the code
used to test for connection completion will never execute, and you should call
the test yourself or invoke TCPSession::Initial in your modified initial. Second, it was a
little broken.
What I suspect is happening is that your packet read/write calls are occuring before
the socket has actually connected (it used delayed "connection" in the constructor)
and this is why you get an immediate error.