[aprssig] Does anybody know what APZMVA is?

[Frank Knobbe]

On 11/7/2015 4:17 PM, Andrew P. via aprssig wrote:
> Greetings.
>
> I've noticed an unusual new experimental tocall value APZMVA, that 
> seems to be associated with some oddly formatted APRS-IS messages. I 
> was just curious what that might be.
>
> Regarding the unusual formatting (which probably has nothing to do 
> with the APZMVA program, as I am seeing from other tocalls as well),
I 
> am seeing packets from the APRS-IS that look like this:
>
>
K4FHK-15>APZMVA:K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64a2_072105zI</yn8U#*n 
> __I-65-N DEBRIS, LEFT LNS BLOCKED


Greetings,

I'm the developer of the TNMVA project. I double-checked the code and
also monitored network traffic to the APRS-IS server, and I am not
seeing this issue. I monitored the network sessions with ngrep.
66.179.102.190 is my server running the TNMVA and other APRS
applications. The packets are sent to APRS-IS like so:

T 2015/11/09 13:52:53.464157 66.179.102.190:1379 -> 52.0.40.3:14580 (iad2.aprs2.net)

user K4FHK-IS pass ***** vers TN-MotorVehicleAccidents V0.6 filter m/1
K4FHK-IS>APZMVA,TCPIP*:!3559.03NT08623.99W&Originator of TNMVA objects. Send comments to tnmva at knobbe.us
K4FHK-IS>APZMVA,TCPIP*:>Seeking Gaters to RF in Mem/Jax/Chat/Knox/JC. Please email me
K4FHK-15>APZMVA,TCPIP*:;TNMVA64c7*091633zI<c&V9#/0n __I-75-N INCIDENT, ON-RAMP BLOCKED.


I also have another application running that is tapped into APRS-IS as
well, with a different connection. On that connection, I observed the
same object placement as it was propagated and received through APRS-IS,
and it appears to arrive properly:


T 2015/11/09 13:52:53.800449 144.202.128.17:14580 (bwi.aprs2.net) -> 66.179.102.190:3886

K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:!3559.03NT08623.99W&Originator of TNMVA objects. Send comments to tnmva at knobbe.us
K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:>Seeking Gaters to RF in Mem/Jax/Chat/Knox/JC. Please email me
K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64c7*091633zI<c&V9#/0n __I-75-N INCIDENT, ON-RAMP BLOCKED


K4FHK-IS is the application/server that is injecting objects into
APRS-IS. The objects themselves are injected either with callsign
K4FHK-15 or K4FHK-51.

Note that K4FHK-51 is intended to be APRS-IS only. K4FHK-15 may be
picked up by Igates and brought onto RF. Currently, the only Igate doing
so is my own, and if any such objects are gated back from RF to IS, they
would be coming from callsign K4FHK-3. So your observation of the issue
with callsign K4FHK-15 related to packets are only present on the
APRS-IS side, and were not gated from RF to APRS.



> Note that the sender>tocall section is repeated twice, with a colon 
> (':') delimiting the two occurrences. I'm wondering if this might be 
> an issue with some dialects of the APRS-IS server code (specifically 
> aprsc, since it is the one that shows up for every I-gate I've 
> back-tracked), should my application not be reading the TCP socket 
> connection fast enough, that the server might get the first part of a 
> message stuffed in the stream, and then discards the rest of the 
> message because of a TCP window overflow. That would make this appear 
> like two concatenated messages with most of the first message gone, 
> including the CRLF delimiter between the two messages. I've got a
48Kb 
> TCP window size configured in my application, so there should be 
> plenty of kernel-level buffering to allow for any pauses at the 
> application level.
>
> The occurrence doesn't seem to be a function of the incoming message
rate.


I'm not sure that this is a timing issue. While the status and object of
K4FHK-IS are sent out rapidly, followed by any objects from K4FHK-51,
any interspersed object from K4FHK-15 would incur a pause due to the
server controlled throttling of these objects intended for RF.

If multiple IS-only packets can not be sent in succession, I can
certainly add a sleep time of a second or two between these, but given
the low amount of successive packets, I didn't think that would be
necessary. I think there are other applications out there
(Metar/weather, Winlink, etc) that also send large batches onto IS
without wait times between packets.


BTW: I just joined this list today, since your mentioning of my call
sign and MVA application was forwarded to me by a fellow Ham (Thanks
Andrew!). I can write up a short introduction of myself and the TNMVA
service and post it to this list shortly, if this is proper etiquette
and desired on this list. 

There is also another application I developed and would like to
introduce to the community as well. For that application, I would like
to "apply" for an APRS-IS callsign, so I would like to seek your input
on the application itself, and the proper process of acquiring and using
a tactical, IS-only callsign.


Best regards,
Frank Knobbe, K4FHK