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