[boost] Re: Sockets!

From: Christopher Currie (christopher_at_[hidden])
Date: 2003-10-30 14:04:17

Jessie Hernandez wrote:
> Well, I just finished uploading a new version of my "socketstream"
> classes (which has been renamed to be in "boost::net"). It is in the
> Yahoo files section under the "socketstream" folder
> (net-20031024-1.tar.gz ).
> 
> I'd like to get feedback on the current state of the library and see
> what can be improved (I'm mostly interested in the design aspect).
> Forgive me for not providing example programs up front, but I hope to
> add this soon (for now, the test.cpp file provides a few samples).
> Thanks.

I've finally had a chance to sit and look at this, sorry for the delayed 
response. My impression is very good, you've obviously put a lot of work 
into this. Keep at it!

I'm somewhat concerned about the ErrorPolicy parameter in your 
framework. I'm glad to see that you've put in a method of reporting 
errors other than throwing exceptions around, because there are 
instances where I cannot affort the stack unwinding for something as 
common as "connection_refused".

But your current implementation has two drawbacks:

1. I'm unable to pass information to my policy on construction.

You create the policy object internally to your socket, using a default 
constructor. However, I might want a policy object holds a function 
pointer, so that my policy can call back to objects of my own. I might 
want that to be a different object for each of my sockets, but as it 
stands I have no control.

To correct this, your socket constructors would need a parameter to pass 
in a copy-constructable policy object; or if you want to allow 
non-copyable policies, a pointer to such an object (maybe even an 
auto_ptr to allow the socket to take ownership).

2. I'm unable to change the existing policy at run-time.

Having the policy as a template paramter means that my policy is fixed 
for a given instance of an object. If cirumstances change, in order to 
change my policy I'm forced to create a new socket instance, which 
effectively means closing and reopening my connection just so I can 
change the way errors are reported.

Having a function that would allow me to replace the existing policy 
would help. But this only allows me to replace it with a policy of the 
same type, since the type is enforced by the template. If I want a 
drastically different policy, I either need to have a single policy type 
that enforces multiple policies, or the socket would need to accept 
pointers to the policy type, so I could implement a policy inheritance 
hierarchy, which would then eliminate much of the advantages of having 
the policy be a template in the first place.

Is this over the top? Possibly. But for these reasons, I'm not sold on 
the idea of using a template to enforce policy in this case. Most 
likely, there are two main error handling scenarios; throwing an 
exception, or returning (or setting) an error code.

Exceptions are seen as being more OO-like, but they have performance 
penalties that are unacceptable in some situations. Ultimately, we might 
be best off implementing some variation of the iostreams model: define a 
collection of error codes, and the user is able to set an exception mask 
to determine which errors generate exceptions.

Although I haven't had a lot of time to analyze it, things look good so 
far otherwise, so keep up the good work.

Christopher