Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-07-26 14:06:07


Being a spread as thin as I currently am, I probably shouldn't volunteer
to help too much with this. However, at work I'm currently doing some
socket programming and have gone through a couple iterations on what I
think a simple socket API should look like. I started by looking at the
unix socket API and at the ACE API. I'm by no means and expert in socket
programming, but perhaps I can offer a good "stupid user" point of view.

The main requirement I see for a C++ socket API is that the protocal
(which functions should be invoked in which order) should be enforced
through the C++ type system by carefully deciding what classes should
exist, how objects are created, and which operations are available on each
class. For example, this is why the ACE API has the separate Acceptor and
Connector classes.

Here's a simple example demonstrating what I think the API should look
like. First, the "server" process. Creating and instance of
socket_acceptor class puts the server in "listening" mode. A
server_connection can then be constructed from the acceptor. Note that it
is impossible to create a server_connection if you don't already have a
valid socket_acceptor constructed, thereby enforcing the protocal.

If the construction on the server_connection succeeds then a connection
has been "accepted". If not an exception is thrown. The server_connection
can then be used to send and receive messages. The destructor for the
server_connection closes its socket descriptor. Likewise, the destructor
for the socket_acceptor closes its descriptor.

#include "socket.hpp"

int main()
{
  dsl::location_t location = { "pc-jeremy.research.att.com", 6543 };
  try {
    dsl::socket_acceptor s(location);
    dsl::server_connection c(s);
    char msg[] = "Hello world";
    c.send(msg, strlen(msg) + 1);
    char buffer[20];
    c.receive(buffer, 20);
    std::cout << buffer << std::endl;
  } catch(const dsl::socket_error& e) {
    std::cerr << "dsl socket error: " << e.what() << std::endl;
  }
  return 0;
}

Next the client process. Instead of having a separate Connector and Stream
class as in ACE, I think a single class makes for a simpler interface on
the client side. A client_connection object can be created that both
creates the socket descriptor and connects to the server. If the
construction of the object succeeds then a connection has been established
and can be used to send and receive. Again, the destructor of the
client_connection closes the socket descriptor.

#include <string>
#include "socket.hpp"

int main()
{
  dsl::location_t location = { "pc-jeremy.research.att.com", 6543 };
  try {
    dsl::client_connection c(location);
    char buffer[20];
    c.receive(buffer, 20);
    std::cout << buffer << std::endl;
    char reply[] = "Hello yourself";
    c.send(reply, strlen(reply) + 1);
  } catch (const dsl::socket_error& e) {
    std::cerr << "dsl socket error: " << e.what() << std::endl;
  }
  return 0;
}

I've attached the prototype.

Taking a quick glance at Joseph's UML diagram, I see classes with lots of
member functions like "bind", "accept", and "connect"... this scares me
because I'd have to read the documentation to figure out what they mean
and in which order I should call them. What happens when I call them in
the wrong order?

Cheers,
Jeremy

On Thu, 26 Jul 2001, Beman Dawes wrote:
> Joseph Berrios, a grad student at the University of Florida, has been
> working on a Sockets library for Boost at my urging. I provided him with a
> list of requirements, and he has been reading the literature and has gone
> through a couple of design iterations.
>
> The UML diagram for his current design is at
> http://www.cise.ufl.edu/~jberrios/Sockets.jpg
>
> His overall grasp of C++ interface/implementation principles seems
> reasonable, although I haven't seen enough examples to be sure. But his
> detailed C++ coding skills, including meeting Boost's requirements and
> guidelines, seem to need further development.
>
> Would anyone like to volunteer to work with Joseph as a mentor and/or
> co-author for a Boost Sockets Library?
>
> If so, please contact him at jberrios_at_[hidden]
>
> --Beman
>
>
> Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

----------------------------------------------------------------------
 Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate, IU B'ton email: jsiek_at_[hidden]
 Summer Manager, AT&T Research phone: (973) 360-8185
----------------------------------------------------------------------





Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk