One Point on the backend side is sync between servers if any server should be able to handle any part of a long time transaction ("association") with any client.
Or am I misunderstanding everything? 73 de Klaus"Offline" now for an undetermined couple of days, but hopefully adressable as pskmail@xxxxxxxxxx tomorrow or the day after.
Am 21.04.2011 19:36, schrieb Pär Crusefalk:
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 PA0RilHi 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
