[pskmail] Re: Unconnected email
- From: Pär Crusefalk <per@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 21 Apr 2011 19:36:44 +0200
In the simple unconnected email case it could be the client requesting
email/headers from a certain server. For instance the client has
registered email details at a server and can then request email from
there. I cant really see that we can handle it as a general request to
all servers, at least not at the moment.
While on this subject its really unfortunate that encryption is not
allowed, maybe we should think about a one time pad like solution only
for access control?
XYL wants me to leave the desk and get some fresh air now and I guess
she has a point, time to head out :-).
73 de Per
SM0RWO
tor 2011-04-21 klockan 11:49 -0500 skrev David R. Wilson:
> 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:
