[pskmail] Re: Unconnected email

  • From: "Rein Couperus" <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Thu, 21 Apr 2011 20:01:44 +0200 (CEST)

The direction is reversed... multicast is 1->n, not n->1...

Rein PA0R

>If this is done, what happens when multiple stations see the traffic?
>Does it end up being sent from many stations to the same destination?
>
>Dave
>KU4B
>
>
>On Thu, 2011-04-21 at 15:34 +0200, Pär Crusefalk wrote:
>> 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: