asio socket connection state
Is there any way to query a stream_socket for its connection state? Also when a connection is closed by a peer during a read operation what error should be expected? eof, not_connected, fault, operation_aborted all seem reasonable.
On Thu, 12 Jan 2006, christopher baus wrote:
Also when a connection is closed by a peer during a read operation what error should be expected?
eof, not_connected, fault, operation_aborted all seem reasonable.
For a TCP socket, I would expect it to return eof, since that is how TCP sockets work. -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2005 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<<
On Thu, 12 Jan 2006, christopher baus wrote:
For a TCP socket, I would expect it to return eof, since that is how TCP sockets work.
read() and recv() return 0 as the number of bytes read when the socket is shutdown for reading. AFAIK, that's the only way to determine that state from the socket API.
Right. That's an eof for a TCP socket. Sorry if that wasn't clear from what I typed. -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2005 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<<
On Thu, 12 Jan 2006, christopher baus wrote:
Also when a connection is closed by a peer during a read operation what error should be expected?
eof, not_connected, fault, operation_aborted all seem reasonable.
For a TCP socket, I would expect it to return eof, since that is how TCP sockets work.
I tested it on Windows and it does indeed return eof. It might be worth while to document this with the read functions.
On Thu, 12 Jan 2006, christopher baus wrote:
Also when a connection is closed by a peer during a read operation what error should be expected?
eof, not_connected, fault, operation_aborted all seem reasonable.
For a TCP socket, I would expect it to return eof, since that is how TCP sockets work.
I tested it on Windows and it does indeed return eof. It might be worth while to document this with the read functions.
Here's the class I'm using to track the socket state in my application code. I am setting the state in my event handlers (which is rather error prone), but asio could manage it internally. class stream_socket_connection_state { public: stream_socket_connection_state():state_(DISCONNECTED){} void connect() { if(DISCONNECTED == state_){ state_ = CONNECTED_FOR_READ_AND_WRITE; } // // ignore attempts to reconnect socket } void shutdown_read() { if(CONNECTED_FOR_READ == state_){ state_ = DISCONNECTED; } else if(CONNECTED_FOR_READ_AND_WRITE == state_){ state_ = CONNECTED_FOR_WRITE; } // // ignore re-shutting down. } void shutdown_write() { if(CONNECTED_FOR_WRITE == state_){ state_ = DISCONNECTED; } else if(CONNECTED_FOR_READ_AND_WRITE == state_){ state_ = CONNECTED_FOR_READ; } // // ignore re-shutting down. } void disconnect() { state_ = DISCONNECTED; } // // Most apps only care if they can read or write // to a socket, but all states can be determined. bool connected_for_read() { return CONNECTED_FOR_READ || CONNECTED_FOR_READ_AND_WRITE; } bool connected_for_write() { return CONNECTED_FOR_WRITE || CONNECTED_FOR_READ_AND_WRITE; } private: enum SOCKET_STATE { DISCONNECTED, CONNECTED_FOR_READ, CONNECTED_FOR_WRITE, CONNECTED_FOR_READ_AND_WRITE }; SOCKET_STATE state_; };
Hi Christopher, --- christopher baus <christopher@baus.net> wrote:
On Thu, 12 Jan 2006, christopher baus wrote:
Also when a connection is closed by a peer during a read operation what error should be expected?
eof, not_connected, fault, operation_aborted all seem reasonable.
For a TCP socket, I would expect it to return eof, since that is how TCP sockets work.
I tested it on Windows and it does indeed return eof. It might be worth while to document this with the read functions.
Yep, eof is the error for when the connection is cleanly closed by the peer. It is currently documented for the corresponding sync functions. I'm also planning to document all of the errors that can be returned by various operations.
Here's the class I'm using to track the socket state in my application code. I am setting the state in my event handlers (which is rather error prone), but asio could manage it internally.
Actually no, I don't think it's appropriate for asio to manage this state internally. Completion notification is decoupled from the originating object, which means that: - The completion handlers can execute in a different thread to that which is initiating operations, so some form of synchronisation would be required to update the state. - The socket object may not even still exist at the point when the completion notification is received. The knowledge of object lifetime and synchronisation is held in the application's design, so I think that the application is the only safe place to update this sort of information. However, in the programs that I have seen asio used in, there has been no need to maintain this sort of state. The state of the socket is instead reflected by the part of the program you're in (e.g. which event handler you're in). If the socket changes state you start using a different event handler. And it's not just socket state changes that can use this approach, but application protocol state changes as well. Cheers, Chris
Actually no, I don't think it's appropriate for asio to manage this state internally.
Ok I can live with that. I'm trying to integrate in "legacy" code which queries for the the socket state. The HTTP parser attempts to determine the end of an HTTP 0.9 type request by testing if the socket is closed for read.
Is there any way to query a stream_socket for its connection state? Also when a connection is closed by a peer during a read operation what error should be expected?
eof, not_connected, fault, operation_aborted all seem reasonable.
I should note that a tcp socket can have four connection states. closed, open for read, open for write, open for read and write It is often useful to know what state the socket is in before attempting an operation. Once the state is determined by a low level operation (open, send, recv, close, shutdown) the state can be stored with the socket. If this isn't stored in the stream_socket applications must carefully parse the error codes, and store that state themselves. I have found bugs code that didn't handle 1/2 connected sockets properly. Unix nc (netcat) performs a write shutdown when it reads eof from stdin, but leaves read open, so it is good for testing this.
participants (3)
-
Chris Cleeland -
christopher baus -
Christopher Kohlhoff