maindocs.h
author Jens Alfke <jens@mooseyard.com>
Sun May 25 12:32:47 2008 -0700 (2008-05-25)
changeset 5 2c4bb6968927
parent 4 2bd9d60a2c46
child 8 6f539dd9921c
permissions -rw-r--r--
More documentation.
     1 //
     2 //  maindocs.h
     3 //  MYNetwork
     4 //
     5 //  Created by Jens Alfke on 5/24/08.
     6 //  Copyright 2008 Jens Alfke. All rights reserved.
     7 //
     8 // This file just contains the Doxygen comments that generate the main (index.html) page content.
     9 
    10 
    11 /*! \mainpage MYNetwork: Mooseyard Networking Library, With BLIP Protocol Implementation
    12  
    13     <center><b>By <a href="/Jens/">Jens Alfke</a></b></center>
    14  
    15 \section intro_sec Introduction
    16  
    17     MYNetwork is a set of Objective-C networking classes for Cocoa applications on Mac OS X.
    18     It consists of:
    19     <ul>
    20     <li>Networking utility classes (presently only IPAddress);
    21     <li>A generic TCP client/server implementation,
    22         useful for implementing your own network protocols; (see TCPListener and TCPConnection)
    23     <li>An implementation of <a href="#blipdesc">BLIP</a>, a lightweight network protocol I've invented as an easy way
    24         to send request and response messages between peers. (see BLIPListener, BLIPConnection, BLIPRequest, etc.)
    25     </ul>
    26  
    27 \section license License and Disclaimer
    28  
    29  MYNetwork is released under a BSD license, which means you can freely use it in open-source
    30  or commercial projects, provided you give credit in your documentation or About box.
    31  
    32  As I write this (May 2008), MYNetwork is still very much under development. I am using it as the foundation of my own commercial products, at least one of which is currently at about the alpha stage. I'm making changes to this code as I see fit, fairly often.
    33  
    34 That's good, in that the code is getting real-world use. But it also means that APIs and functionality are subject to change. (Of course, the entire revision tree is always available, so you're free to stick with any revision you like, and even "cherry-pick" desired changes from future ones.)
    35  
    36 Not all of this code gets thoroughly exercised by my test cases or my applications, so some things may not work. Obviously, this code comes with no warranty nor any guarantee of tech support, though I will try to do my best to help out. Hopefully the source code is clear enough to let you figure out what's going on.
    37  
    38 If you come across bugs, please tell me about them. If you fix them, I would love to get your fixes and incorporate them. If you add features I would love to know about them, and I will incorporate them if I think they make sense for the project. Thanks!
    39 
    40 \section blipdesc What's BLIP?
    41  
    42 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. 
    43  
    44 BLIP was inspired by <a
    45 href="http://beepcore.org">BEEP</a> (in fact BLIP stands for "BEEP-LIke Protocol") but is
    46 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.)
    47  
    48 \subsection blipfeatures BLIP Features:
    49 
    50  <ul>
    51  <li>Each message is very much like a MIME body, as in email or HTTP: it consists of a
    52 blob of data of arbitrary length, plus a set of key/value pairs called "properties". The
    53 properties are mostly ignored by BLIP itself, but clients can use them for metadata about the
    54 body, and for delivery information (i.e. something like BEEP's "profiles".)
    55 
    56 <li>Either peer can send a request at any time; there's no notion of "client" and "server" roles.
    57  
    58 <li> Multiple messages can be transmitted simultaneously in the same direction over the same connection, so a very long
    59 message does not block any other messages from being delivered. This means that message ordering
    60 is a bit looser than in BEEP or HTTP 1.1: the receiver will see the beginnings of messages in the
    61 same order in which the sender posted them, but they might not <i>end</i> in that same order. (For
    62 example, a long message will take longer to be delivered, so it may finish after messages that
    63 were begun after it.)
    64 
    65 <li>The sender can indicate whether or not a message needs to be replied to; the response is tagged with the
    66 identity of the original message, to make it easy for the sender to recognize. This makes it
    67 straighforward to implement RPC-style (or REST-style) interactions. (Responses
    68 cannot be replied to again, however.)
    69 
    70 <li>A message can be flagged as "urgent". Urgent messages are pushed ahead in the outgoing queue and
    71 get a higher fraction of the available bandwidth.
    72 
    73 <li>A message can be flagged as "compressed". This runs its body through the gzip algorithm, ideally
    74 making it faster to transmit. (Common markup-based data formats like XML and JSON compress
    75 extremely well, at ratios up to 10::1.) The message is decompressed on the receiving end,
    76 invisibly to client code.
    77  
    78 <li>The implementation supports SSL connections (with optional client-side certificates), and Bonjour service advertising.
    79 </ul>
    80  
    81 \section config Configuration
    82  
    83     MYNetwork requires Mac OS X 10.5 or later, since it uses Objective-C 2 features like
    84     properties and for...in loops.
    85  
    86     MYNetwork uses my <a href="/hg/hgwebdir.cgi/MYUtilities">MYUtilities</a> library. You'll need to have downloaded that library, and added
    87     the necessary source files and headers to your project. See the MYNetwork Xcode project,
    88     which contains the minimal set of MYUtilities files needed to build MYUtilities. (That project
    89     has its search paths set up to assume that MYUtilities is in a directory next to MYNetwork.)
    90 
    91 \section download How To Get It
    92 
    93     <ul>
    94     <li><a href="/hg/hgwebdir.cgi/MYNetwork/archive/tip.zip">Download the current source code</a>
    95     <li>To check out the source code using <a href="http://selenic.com/mercurial">Mercurial</a>:
    96     \verbatim hg clone /hg/hgwebdir.cgi/MYNetwork/ MYNetwork \endverbatim
    97     <li>As described above, you'll also need to download or check out <a href="/hg/hgwebdir.cgi/MYUtilities">MYUtilities</a> and put it in 
    98     a directory next to MYNetwork.
    99     </ul>
   100 
   101     Or if you're just looking:
   102 
   103     <ul>
   104     <li><a href="/hg/hgwebdir.cgi/MYNetwork/file/tip">Browse the source code</a>
   105     <li><a href="annotated.html">Browse the class documentation</a>
   106     </ul>
   107  
   108     There isn't any conceptual documentation yet, beyond what's in the API docs, but you can 
   109     <a href="/hg/hgwebdir.cgi/MYNetwork/file/tip/BLIP/Demo/">look
   110     at the sample BLIPEcho client and server</a>, which are based on Apple's 
   111     <a href="http://developer.apple.com/samplecode/CocoaEcho/index.html">CocoaEcho</a> sample code.
   112  
   113  */