Re: General Sockets Questions?
Re: General Sockets Questions?
- Subject: Re: General Sockets Questions?
- From: Cameron Kerr <email@hidden>
- Date: Thu, 18 Nov 2004 01:17:54 +1300
- Resent-date: Thu, 18 Nov 2004 01:19:07 +1300
- Resent-from: Cameron Kerr <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: apple network dev <email@hidden>
On 17/11/2004, at 4:05 AM, Carlos Eduardo Mello wrote:
Also, I'd like to ask about good reading material on sockets
programming, other than Richard Stevens' Books (which I've ordered but
are gonna take a while to arrive). I started out with Beej's tutorial
and managed to send a few bytes across a TCP connection, but I need
more.
Funny, if you hadn't mentioned either, I would have referred you to
both.
Particularly about how to set up a good solid server/client engine for
simple needs.
UNP will give you the low-down on various client/server architectures,
but I know of no good reference guiding the reader through protocol
handler construction or application layer protocol design, which is
why, as a teaching fellow, I am about to write my own.
I will offer the following words of wisdom though:
NEVER use stdio functions on a network socket, even though this makes
it harder to read from the socket conveniently. (This applies to other
languages as well, such as Perl's <> operator, or many other languages
getline function).
DO make your own buffered reader (I'll discuss this later)
IF your protocol (which you should spend ample time designing) is
message based, THEN make your buffered reader message aware, using
pointers to functions.
DO look at how other frameworks, such as Perl's POE module (Perl Object
Environment) is structured.
DO learn to use the regular expression library. I strongly suggest you
make a nice wrapper function to more easily match and extract.
= On the design and implementation of a buffered reader =
Of the requirements for a useful reader, the ones that stand out the
most are 1) being able to pass in a pointer to function that says
whether there is a complete message in the buffer, and 2) being able to
retrieve said message. 3) The design must be thread-safe, with no
global variables, meaning the user must allocate a structure which
stores the buffer for the stream (in much the same way a FILE structure
is opened).
Because we are dealing with sockets, we _really_ don't want to use
anything that would prevent us from using the full power of the BSD
Sockets API. In practice, this is quite simple, the only thing to be
sure of is that you check if there is anything in your buffer before
reading from the socket (read()ing from the socket should only be done
by your protocol handling library.
I shall outline (albeit vaguely) a library I designed and implemented
this year, which my network programming students used. It is suitable
when you can identify a "message", whether it be a line, or a set of
lines delimited by a blank line. The definition of "message" is up to
the user of the API. I don't think I have rights to give you code, but
here is the API for the protohdl library I created. Note that some of
the names could be tidied up, but its quite reusable, although it
hasn't received much API testing.
ph_alloc_buf is a function that returns a ph_buf structure, which
contains a void * buffer, the associated socket (passed in as a
parameter), and two user provided function pointers, which sees if a
complete message is available, and another to return a user-defined
structure which is the message.
ph_get_message is passed the ph_buf structure, and returns the
user-specified structure. It is responsible for moving bytes from the
socket buffer to the ph_buf buffer when they are available; calling the
user-specified checker and extractor functions; dequeuing the bytes
that the extractor has indicated it wants to remove; and returning the
structure the user-specified extractor has allocated and filled in.
This way, the protohdl library is protocol agnostic, and just does the
boring heavy lifting of working with network sockets (if you're not
convinced, try writing an efficient get_line_from_socket function). All
the protocol specific format details are up to the functions (the
checker and extractor) that the API user provides.
If you're not familiar with pointers to functions, get your hands on a
copy of "The C Programming Language". Function pointers can be used in
other programming languages, but likely use different terminology, such
as function references in Perl.
--
Cameron Kerr
email@hidden; http://humbledown.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden