Re: [boost] Re: sockets library

From: Iain.Hanson_at_[hidden]
Date: 2001-12-20 10:16:18

Efficientcy is not the only reason that iostreams are not suitable for the 
loewest layer of a C++ networking library. They do not map well onto any of the 
packet oriented protcols such as those build on UDP.

ASCII protocols are far from in the majority either standardosed or propriarty.

IMHO efficiency, functionality, and type-saftey are all key issues in the lowest
layer of a network programming library.

/ikh

______________________________ Reply Separator _________________________________
Subject: Re: [boost] Re: sockets library
Author:  dylan (dylan_at_[hidden]) at unix,mime
Date:    20/12/01 10:53

--- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote: 
> mfdylan wrote:
> > 
> > --- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote: 
> > >
> > > I'm convinced that iostreams should be reserved strictly for 
human
> > > readable text I/O, and not used for computer-to-computer 
> > communication,
> > > such as sockets.
> > >
> > Well, er, most (if not all) common internet protocols are in fact 
> > human readable.  For a start they are easy to debug, and work
> > regardless of byte-ordering or floating point storage mechanisms. 
> > In fact unless efficiency (in space or time) is a problem, ascii 
> 
> In library design (as opposed to application design), efficiency is 
> _always_ a problem. ("You can build a safe library on top of an
> efficient one, but not the other way around." -- James Kanze.) If 
you
> don't give it priority in library design, you're narrowing your user 
> base to a subset of potential users.
     
I agree entirely, but I don't think it's applicable to such a great 
degree in this case: when dealing with socket I/O, almost any CPU 
usage in your application processing input/output format is 
overwhelmed by network overhead (even to localhost, at least 
certainly under NT - unices tend to be a little more efficient). 
Obviously with socket I/O quantity of data is more of an issue, and 
if the binary representation of your data is significantly smaller 
than the ascii representation (not always the case) then you might 
have a good argument for sticking with binary.
The binary_stream class I wrote coupled with a streambuf derived 
socketbuf compiles to quite acceptably terse code (at least using 
VC), and is not noticeably slower than anything I could hand code (by 
noticeably I mean physically timing how long it takes to transit a 
few million objects across a loopback connection).  The same is true 
when used with a filebuf (providing you wait for the file to be 
flushed to disk).
     
Dylan
     
     
     
     
Info: http://www.boost.org  Send unsubscribe requests to: <mailto:boost-unsubscr
ibe_at_[hidden]> 
     
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.