Hello Robert, I've the same problem as Maciej. You believe that this problem relies on the streambuf implementation - I think it doesn't. It doesn't matter if you use a buffered streambuf with flushing it or an unbuffered streambuf - the archive blocks in basic_text_iprimitive.hpp, line 80, 'is >> t'. I don't know what do you mean with 'streambuf implementation needs enhancement'? The streambuf reads n bytes from the socket or writes n bytes to the socket as it was requested by its interface. So it reads n bytes from the socket and writes n bytes to the socket as it was passed to the stream which uses the socket_streambuf. It doesN#t make assumptions about the outer context it is used. In the read action it returns 0 if the peer has closed the socket and no more data will be available - so you have to return std::char_traits< char >::eof() in order to indicate the EOF of the stream. If the socket (blocking mode) is still open and you try to read n bytes from a socket you will be blocked until n bytes can be read from the socket (peer has written at least n bytes to the socket). I could verify that boost::archive blocks because it tries to read more bytes than available. The client writes an archive with 29 bytes (printed out from the streambuf - value was '22 serialization::archive 3 0') to the socket in one operation. On the peer socket the archive tries to read 4096 bytes from the socket (also printed out from streambuf operation) in one call. So this must be block because you can only read 29 bytes from the socket! As you can see this problem is raised by the boost::archive. Oliver