ANN: MYNetwork library, including abstract TCP client/server and BLIP protocol
ANN: MYNetwork library, including abstract TCP client/server and BLIP protocol
- Subject: ANN: MYNetwork library, including abstract TCP client/server and BLIP protocol
- From: Jens Alfke <email@hidden>
- Date: Sun, 25 May 2008 14:15:59 -0700
I've just put up a preliminary release of an open-source Cocoa library
called MYNetwork, which extracts some of the networking code from the
app I'm working on, Cloudy.
http://mooseyard.com/projects/MYNetwork/
MYNetwork includes an abstract TCP client and server implementation,
which may be useful if you want to implement your own network
protocols; but its main attraction is an implementation of BLIP, a new
network protocol I designed after giving up[1] on using an existing
BEEP implementation for my app.
Here's the introductory blurb about BLIP, copied from the
documentation...
What's BLIP?
BLIP is a message-oriented network protocol that lets the two peers on
either end of a TCP socket send request and response messages to each
other. It's a generic protocol, in that the requests and responses can
contain any kind of data you like.
BLIP was inspired by BEEP <http://beepcore.org> (in fact BLIP stands
for "BEEP-LIke Protocol") but is deliberately simpler and somewhat
more limited. That results in a smaller and cleaner implementation,
especially since it takes advantage of Cocoa's and CFNetwork's
existing support for network streams, SSL and Bonjour. (BLIP is
currently a bit under 2,000 lines of code, and the rest of the
MYNetwork classes it builds on add up to another 1,500. That's at
least an order of magnitude smaller than existing native-code BEEP
libraries.)
BLIP Features:
• Each message is very much like a MIME body, as in email or HTTP: it
consists of a blob of data of arbitrary length, plus a set of key/
value pairs called "properties". The properties are mostly ignored by
BLIP itself, but clients can use them for metadata about the body, and
for delivery information (i.e. something like BEEP's "profiles".)
• Either peer can send a request at any time; there's no notion of
"client" and "server" roles.
• Multiple messages can be transmitted simultaneously in the same
direction over the same connection, so a very long message does not
block any other messages from being delivered. This means that message
ordering is a bit looser than in BEEP or HTTP 1.1: the receiver will
see the beginnings of messages in the same order in which the sender
posted them, but they might not end in that same order. (For example,
a long message will take longer to be delivered, so it may finish
after messages that were begun after it.)
• The sender can indicate whether or not a message needs to be replied
to; the response is tagged with the identity of the original message,
to make it easy for the sender to recognize. This makes it
straighforward to implement RPC-style (or REST-style) interactions.
(Responses cannot be replied to again, however.)
• A message can be flagged as "urgent". Urgent messages are pushed
ahead in the outgoing queue and get a higher fraction of the available
bandwidth.
• A message can be flagged as "compressed". This runs its body through
the gzip algorithm, ideally making it faster to transmit. (Common
markup-based data formats like XML and JSON compress extremely well,
at ratios up to 10::1.) The message is decompressed on the receiving
end, invisibly to client code.
• The implementation supports SSL connections (with optional client-
side certificates), and Bonjour service advertising.
—Jens
[1] http://mooseyard.com/Jens/2008/05/the-fine-line-between-clever-and-stupid/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden