[pskmail] Re: Unconnected email
- From: "Rein Couperus" <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 21 Apr 2011 12:29:22 +0200 (CEST)
This is definitely worth investigating, in fact I am working out a concept
at the moment to make this possible in PSKmail 2.0, as part of the Delay
Tolerant
Networking strategy.
Bulk transfers are based on PSKmail connected mode ARQ, which has as its
biggest advantage
that is is error free and very fast and reliable for a 500 Hz bandwidth.
The disadvantage is that on bad channels (marginal condx or qrm) a connected
session can take
a very long time, or even break. That is why we included the resume function
for mail and file transfers.
But the tight coupling between server and client, and the critical timing
necessary for an efficient ARQ
session make it less than ideal for 'difficult circumstances'.
For a station with marginal operating conditions (low power, bad antenna) the
window of
opportunity can be very narrow. For such stations it will be necessary to put
another service alongside
the ones we have running in PSKmail 1.0, based on a different set of criteria:
• Less tight coupling between the nodes, associations rather than sessions.
• Active in the background, giving priority to connected sessions
• No time limit on the duration of an association between the nodes (days
rather than minutes)
• Opportunistic behavior, so the windows of opportunity on a channel are used
efficiently, which may include periodic band hopping within the context of an
association
• Back off algorithm to prevent nodes from dominating the channel, and allowing
other nodes to use the channel
• DAMA access control on the server in order to use the channel efficiently
• Use UI frames and leave the transport layer function to the application (like
we already do for APRS)
• Minimize frame overhead to fit the channel bandwidth (NO AX25)
• NAK based transport control, enabling multicast to groups
• Automatic association admin and control, to keep sysop workload to a minimum
• Stream based transfer, an association can support multiple streams
• Long time buffering of stream data belonging to an association
The idea is to send a number of requests to the server, which will be queued
there,
and the output of those requests are sent back whenever the channel is
available.
Depending on channel load and availability this could take a lot of time..
The list is longer than this, but you will understand that a lot of work is
waiting...
For the APRS functions in PSKmail it will mean that:
• functions will be created which enable reliable beaconing (repeat + ack)
• message transfer will become a lot more reliable (repeat + ack)
• automated transfer of data for the map application will become possible (push
function for position lists)
There is of course no free lunch.... all this will require bandwidth, and lots
of frequency planning.
But I hear only complaints that the number of hams is shrinking any way... :-)
What say?
73, Rein PA0Ril
>Hi all,
>
>This is mostly just an idea but perhaps it should be investigated
>further?
>
>Yesterday I talked to Oleg Kazharsky that participated in the polar ring
>arctic expedition. Unfortunately they had some technical difficulties
>with their vehicles so the expedition has been aborted. Unfortunate but
>the main thing is of course that they are safe and can possibly try
>again later (provided there are sponsors etc).
>
>The plan was to use pskmail during the expedition and the main use was
>to be aprs with position reports and short web page updates by using
>unconnected pskaprs emails. When I asked Oleg what else he would want to
>see in there then he wanted something similar to pskaprs email but in
>the opposite direction. Like push email from server to client.
>With the conditions on the pole, and the tiny vertical antenna on the
>vehicles, it can sometimes be difficult to establish a stable arq
>connection. There are time constraints as well as varying conditions and
>a vehicle that moves up and down a lot.
>
>They are also using iridium but it doesnt work very well and is
>difficult to use so he would like to avoid it as much as possible.
>
>What we could do is have the client send unconnected frames addressed to
>a certain server with a few commands. Provided the user is registered at
>the server then the client could send unconnected frames that can be
>interpreted like:
>
>client->server: get list of my 10 or x latest emails.
>client->server: get my message no x.
>
>The answer to both of these should probably be a short broadcast from
>the server, possibly with a nice and robust mode too. A very robust FEC
>mode would be good here.
>
>This would open up two way email handling also for stations with
>restrictions on use of power (solar powered sailboat for instance).
>The query is short, uses very little power. QRP email :-).
>
>Yes, the negative side of this is that the broadcast from the server can
>be disturbed and an arq connection is of course much better for handling
>emails. But, this new way is extremly fast and consumes very little
>power with the client. Your ideas and worries about this?
>
>73 de Per,
>sm0rwo
>
>
>
Other related posts:
