Re: [boost] Help with a Sockets library?

From: Iain.Hanson_at_[hidden]
Date: 2001-07-27 09:05:16

     Something like this was developed back in about 1994. It was called 
     Sockets++ and if I rember correctly, it inheritted form iostream. At 
     one time, a copy of it was shipped with ACE ( although not any longer 
     ).
     
     I believe that it did not perform as well or as predictablely as ACE's 
     approach.
     
     It would probably be easist th achieve what you are after by reading 
     into a vector < unsigned char >.
     
     /ikh

______________________________ Reply Separator _________________________________
Subject: Re: [boost] Help with a Sockets library?
Author:  georgeh (georgeh_at_[hidden]) at unix,mime
Date:    26/07/01 21:10

     
I also have no time to help with this, but let me talk about something 
connected to any sockets library, and that is non-blocking IO.
     
I want an interface where I don't have to make local buffers, and can, 
once I've determined that the data is there to be read, treat the 
socket transparently like a stream.
     
As an example of what I've been vaguely thinking about being able to do:
     
#include <boost/socket.hpp>
     
int main() {
  boost::socket<char> server("some_server", 1234); 
  // Elide catching of failures to connect
  int size = 0;
  while (1) {
    if (size) {
        if (server.chars_avail(size)) {
          // Read in the message we expect to have & process it.
        }
    } else if (server.chars_avail(2)) {
      char hi, lo;
      server >> hi >> lo;
      size = hi >> 8 + lo;
    }
    // Process other tasks, or sleep for some length of time.
  }
}
     
Some things which I think would be very useful in the kinds of tasks 
I've run into in this domain:
  1) Being able to find the first occurance of a particular character 
in the incoming stream, without consuming all the characters preceding 
it, and without blocking in the case where it is not there to be read 
yet. This is useful for specific-character-delimited protocols.
  2) Being able to 'mark' and rewind a stream to that mark on failure. 
This is needed for protocols where there is no specific delimiter but 
you know when the message is over as you get through it. This can also 
be useful for character-delimited protocols where you expect incomplete 
messages to be rare but occasionally pop up.
  3) Being able to find out if at least N characters are available to 
be read. This is important for message-length-in-a-header protocols.
  4) Otherwise being able to treat the socket as a C++ stream, so that 
operator>> and <<'s can be used internally, with only the highest-level 
piece having to be able to figure out whether a message is complete or 
not.
     
I think some derivations from basic_streambuf and basic_[io]{1-2}stream 
would make these things possible.
     
This is really disjoint from the work on sockets per se, but since it 
is a related task in most uses of sockets, I thought I would mention it 
here.
     
George Heintzelman
georgeh_at_[hidden]
     
     
     
Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_yahoogroups.c
om> 
     
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
     
     

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.