Yes, after I wrote that, I realized there may be some confusion using a colon and would recommend using a comma or something else like a tilde
toggle quoted messageShow quoted text
" ~ " and slot number so not to confuse it with a 'port' .
On 7/31/2018 9:37 PM, Cort N0MJS via Groups.Io wrote:
I believe I just said that I’ll use the IP address and the port… or are you recommend it be a string concatenation of the dotted quad IP address, a colon, and the string representation of the port number?
I’ll be looking for the fastest way to do the match for each packet. I don’t mind spending processor time when a machine registers building the identifier then – a few cycles doesn’t bother me during registration, but here we’re also talking about a match that has to take place on every packet traversing the system * number of clients in the system.
Are you thinking that a string comprehension with an integer to string conversion is the fastest way to do that?
On Jul 31, 2018, at 7:52 PM, Mike KB8JNM <email@example.com> wrote:--
Could it be - "IP:slot"
Just a thought !
On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.
On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <firstname.lastname@example.org> wrote:Cort Buffington
I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.
The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.
Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.