[pskmail] Re: Unconnected email
- From: Pär Crusefalk <per@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 21 Apr 2011 15:34:03 +0200
Cool,
I see where you are headed and its a nice vision, great!
This would be a much more loosely tied connection so I would think you
are approaching unconnected frames with the link logic on a higher
plane. The unconnected email thing could fit nicely in there.
I can see a connect sequence from a client that asks for a certain type
of link, one on one arq or unconnected DTN session etc. We could even
extend it to include even more loosely tied connections. There are
military ships that "connect" to a network and say what "servers" they
will monitor. Then messages are sent as broadcasts and numbered, if the
ship gets all the numbers then it sends nothing. It can check the latest
number when a traffic list is sent and by looking at recently received
messages. If a number is not received then it can look at the traffic
list and decide if it should request a retransmission. For us that could
be a sailing yacht crossing the atlantic, on sailing it sends the route
and requests a web fetch of weather to be sent at xx utc every day for
the next xx days. Weather would be sent and the boat can save on the
batteries...Traffic list can contain the latest message header number
for linked stations... So much work...
73 de Per
sm0rwo
tor 2011-04-21 klockan 12:29 +0200 skrev Rein Couperus:
> 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:
