| Steve's Networked Programming Newsletter
|
Making Nets Work
March
2009
|
|
Thank you for subscribing to my newsletter. I
apologize for not getting the January or February issues
of this newsletter out to you. Between being sick and
buried in work, the newsletter has been on the back
burner for a while. I hope this month's issue is
useful.
To keep in touch with what goes on between newsletter
issues, please keep an eye on my blog. To get even more
fine-grained commentary, you can also now follow me on
Twitter. As always, be sure to forward this
note to other people you work with to be sure they know
what's happening in the world of networked application
development.
|
Stream-Oriented vs.
Message-Oriented Protocols and SCTP
|
C++NPv1
section 1.1 contains a discussion of stream-oriented vs.
datagram-oriented protocols. If you're thinking "No, it
doesn't... I'm looking right at it!" it's because that
section is titled "Connectionless versus
Connection-oriented Protocols." If we're only talking
about TCP and UDP, the distinction is mostly academic.
However, when I was working on an ACE question with a
customer recently, the distinction became more
real.
The Stream Control Transmission Protocol
(SCTP) is
gaining in popularity for certain classes of networked
application because it offers connections (like TCP) but
its data transfers are message-oriented (like UDP).
Since these concepts become distinct in this sort of
case I thought it'd be a good time to isolate the
stream- vs. message-oriented dimension of protocol
selection.
The defining characteristic of a
stream-oriented protocol is that all data transferred is
treated as a simple sequence (or stream) of bytes.
Regardless of how you choose to send (or prefer to
receive) the data, you must always remember that the
data is simply a series of bytes and the protocol does
not honor any concept of records. Any chunks of data
your application sends may be split or coalesced at any
point between your application and the
receiver.
A message-oriented protocol, however,
works in units of messages, not bytes. The sender
decides what a message is - whatever size of data the
sender sends is one message. Each one may be a different
size, but the message unit sent by the sending
application is exactly what will be received; no more,
no less. This brings up the first area where TCPers
often err: when issuing a recv() operation for a
message-oriented protocol, the receiving buffer must be
large enough to hold the entire message, or recv() will
return an error. This differs from the stream-oriented
protocol, where a recv() of any size will simply return
the available bytes, up to the size of the offered
buffer - you can simply receive any remaining bytes with
another recv(). Thus, a receiving application needs to
have an idea of what the largest message will
be.
Message-oriented data transfer offers some
nice conceptual benefits and ease of programming since
there's no need for a receiving application to piece
together received bytes into desired usable segments.
It's not seen often because the primary protocol using
message orientation is UDP. Since UDP doesn't offer the
guarantees of delivery and order that TCP does, and many
applications won't tolerate random loss of data, TCP is
more often used in general. This two-protocol decision
is why "connection-oriented" is often used
interchangeably with TCP (and, thus stream-oriented) and
"connectionless" is often mapped to UDP and, therefore,
message-oriented. However, with the increased use of
SCTP, it's more important to distinguish the two
concepts.
ACE includes the
ACE_SOCK_SEQPACK_Acceptor, ACE_SOCK_SEQPACK_Connector,
and ACE_SOCK_SEQPACK_Association wrappers for SCTP. They
are supported primarily on Linux and Solaris. Since SCTP
is relatively new, native OS support for it is not
widespread. To learn more about SCTP, IBM has a nice
description with examples at http://www.ibm.com/developerworks/linux/library/l-sctp/
- if you have questions about how you might be able to
make use of SCTP, feel free to
ask!
|
Apache Qpid M5
Coming
|
The Apache Qpid team has been busy
improving and extending Qpid for the M5 release, which
should happen in April. Betas of the release are being
tested and things are looking good for an April
release.
I've been working on behalf of Microsoft
to convert the Qpid libraries to build as DLLs instead
of the static libraries built in M4. This will be a big
help to a number of organizations investigating
Qpid-based system deployments.
If you decide to
give Qpid a
whirl, please let me know how it
goes.
|
| Do You Need Help Designing Your
Next System? |
Nobody has to tell you that
designing a well-formed, efficient, maintainable
networked application is hard. You've had to deal with
it. The problem is that networking functionality is
usually in a supporting role to your system's main
purposes, and your skills and experience are much better
used to focus on specific business and technology
issues. It may make more sense to bring in seasoned
expertise to help design a solid networking base in your
next system.
I've helped many companies get great
networked applications built - I may be able to help you
as well. Let's talk and see if I can help take care of
the networking, and let you focus on applying your
expertise and experience to the business features
that'll really help your system stand out.
Call
me at 508-541-9180 or email me at shuston@riverace.com.
| |
|
If you have any ideas for areas of networked
programming you'd like to hear about in future issues,
please email me with your suggestions. In the meantime,
keep those nets working!
Sincerely,
Steve Huston
Riverace
Corporation
| | |
| |
