[pskmail] Protocol extension for Delay Tolerant Networking

From: Rein Couperus <rein@xxxxxxxxxxxx>
To: pskmail@xxxxxxxxxxxxx
Date: Fri, 17 Sep 2010 12:51:38 +0200 (CEST)
PSKmail "protocol 1"  PSKmail protocol 1 is an extension of the pskmail arq 
protocol. Protocol 1 adds a DTN bundle layer on top of the arq protocol layer.  
Why do we need a DTN facility in PSKmail?  PSkmail works as a transaction 
facilitator on the basis of non-volatile agents. I.e. the server erases all 
data after the transaction is completed, a transaction has to be completed 
within 1 session.. Which means that incomplete transactions have to be started 
from scratch. Imagine yourself downloading a 5 kB grib file over an unreliable 
500 Hz wide HF channel. The channel can disappear any moment through QSB, or 
QRM from another station taking over the frequency.. On our shared ham radio 
frequencies this happens regularly, politeness is not abundant in the digital 
mode portions of the bands. Or the British OTH radar on Cyprus kicks in, 
blocking your channel for hours. All in all, even using the adaptive mode 
switching facility the chance of a broken connection is quite large. And Murphy 
will take care that the session will be killed as soon as your file has reached 
the 98% complete mark. You can start from scratch. Would it not be nice if you 
only had to download the remaining 2% as soon as you have found a new clear 
channel? The non-volatile structure of the dumb agents in the pskmail server 
prevented this until now.  PSKmail protocol 1 takes care of this. It adds 2 
things to the arq layer: • A storage facility for incomplete transactions • A 
bundle protocol on top of arq to handle routing and completion of transactions  
 The software modules which handle this bundle protocol will also enable 
message forwarding between pskmail nodes in future.The functionality which has 
been implemented in server 1.0.21 and jpskmail 0.6 only covers completing 
transactions across several connectivity sessions.  The bundle protocol  The 
bundle protocol is built upon a number of message primitives: • FOx: Forwarding 
request (x = message priority) • FY: Accept forwarding • FN: Decline forwarding 
• FR: Reject forwarding • FM: Transaction header • FA: Transaction complete  A 
bundle message contains message priority, routing information, message type, 
(file) name, and length of the message, so that the receiving node knows in 
advance what to do with it. Every transaction gets an ID, which is valid during 
its lifetime. This lifetime is a function of its message priority.  An example: 
~FO5:PA0R:PI4TUE:tmpekJH_78h:m: :1356 meaning: request forwarding mail message 
from PA0R to PI4TUE, transaction code tmpekjH_78h, length 1356 characters.  
another example: ~FO5:PI4TUE:PA0R:hdy6gj:f:grb201009873600.grb:3876 meaning: 
request forwarding file grb201009873600.grb for PA0R, length 3876 If PA0R 
already has a part of the file, he can answer: ~FY:hdy6gj:3085 PI4TUE will now 
send the file, starting with character 3085 
.>FM:PI4TUE:PA0R:hdy6gj:f:grb201009873600.grb:3876 as soon as the whole file 
has been received, PA0R sais: ~FA:hdy6gj and both stations delete the 
transaction.  [Which protocol version is running?  You can easily see which 
protocol version is in place, it is the first character of the Connect request 
and Connect acknowledge packets. If there is a "1", the new protocol is active. 
If it is a "0", the new functionality is not active.  The new protocol has been 
tested extensively on PI4TUE, and it can now be released for alpha testing.  
Both server (pskmail_server-1.0.21.tar.gz) and client (javapskmail.jar) are  
available at http://hermes.esrac.ele.tue.nl/pskmail/alpha  They should be 
backward compatible with earlier versions.  This new development adds a new 
dimension to pskmail, I am sure you will have a lot of fun testing this!!  73,  
Rein PA0R --  http://pa0r.blogspirit.com
[pskmail] Protocol extension for Delay Tolerant Networking

Other related posts:
