[aprssig] Centralised message server

[Andrew Rich]

Is it possible that there is a message only aprs feed ?

Andrew VK4TEC


----- Original Message ----- 
From: "Andrew Rich" <vk4tec at tech-software.net>
To: "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>; "TAPR APRS Mailing 
List" <aprssig at tapr.org>
Sent: Saturday, November 21, 2009 8:21 AM
Subject: Re: [aprssig] Centralised message server


> 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
>
>
> _______________________________________________
> 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.75/2516 - Release Date: 11/20/09 
19:43:00