Re: [boost] asio socket connection state

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-01-13 09:32:14

Hi Christopher,

--- christopher baus <christopher_at_[hidden]> 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