[aprssig] Centralised message server
Andrew Rich vk4tec at tech-software.netFri Nov 20 22:21:55 UTC 2009
- Previous message: [aprssig] Centralised message server
- Next message: [aprssig] Centralised message server
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Keep it for 24 hours and then retry on heard then dump it ----- Original Message ----- From: "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to> To: "Andrew Rich" <vk4tec at tech-software.net>; "TAPR APRS Mailing List" <aprssig at tapr.org> Sent: Saturday, November 21, 2009 5:58 AM Subject: Re: [aprssig] Centralised message server > Since you asked, I've been thinking about an APRS-IS-based message > server that would detect messaging activity, track acks, and offer the > sender to buffer and retry the message if too many retransmissions occur > without an ack. I've also considered the ability for message recipients > to be able to set up alternate delivery addresses (like e-mail) for > non-ack'd messages. > > However, there's some (justified) resistance to "spoofed" source > addresses on APRS packets, so the delayed delivery mechanism is a bit > difficult to add the originator's address when the original message may > have already been a full length. > > If we can work out the behavior of such a program, and don't meet with > much resistance, I believe it could be done similar to CQSRVR, WHO-IS, > and EMAIL servers. > > Here's a possible starting point: > > 1) Monitor message traffic for retries w/o acks > 2) When a "longer than anticipated" delay occurs, send a message to the > sender of the failed message. > 3) Offer to a) Retry, b) Ignore, or c) Never Again the message from > sender to receiver > 4) Option would be sent via reply from sender to server (only one per > sender/receiver at a time) > 5) If c) Never Gain - add sender to "ignore" list. > 6) If b) Ignore - quit processing that message > 7) if a) Retry - Monitor APRS-IS for beacons from recipient and > (here's where it gets iffy) > 8) Send a message to recipient from server informing of buffer message > from sender > 9) Option to a) Receive, b) Ignore, c) Never Again > 10) if c) Never Again - add recipient to "ignore" list > 11) if b) Ignore - quit processing that message > 12) if a) Retry - Send message as if it came from original sender > (spoofed, but with permission on both ends) > > Lynn (D) - KJ4ERJ > > Andrew Rich wrote: >> What do you think of the idea that you sumbit a messages to a server >> running mysql. >> >> Next time the station is heard, the message gets delivered ? >> >> Like what they call a Short Message Server in mobile phones. >> >> Would take to the necessaity off the home user to be running a client >> holding the messages. >> >> You would submit via the web as well through a web page. >> >> Andrew VK4TEC >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> aprssig mailing list >> aprssig at tapr.org >> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig >> > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.425 / Virus Database: 270.14.73/2514 - Release Date: 11/19/09 19:42:00
- Previous message: [aprssig] Centralised message server
- Next message: [aprssig] Centralised message server
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
