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 >> > > >> > > >> > > >> > >> >> >> > > >