UDP multicast of raw gate events

[SSPW]

Rather than clients polling for monitor data, and rather than getting all data, it might make sense to have a udp multicast of each raw event. This would cut down a lot is load on the Pi server. Rather than the full session plus data json structure, just send a simplied token, lap num, lap time structure.

[frezik]

I like this idea in theory. However, multicast can be tricky to setup in practice. It may be particularly tricky on Android and iOS clients (not sure, really).

If load on the Pi due to polling is high, we may be better off finding a way to reduce or offload that.

[SSPW]

Ok. I haven't looked at ease of multicast listeners on any thing except windows.

How many tcp client sockets can the PI hold open?
Maybe clients request connection, are given a port, reconnect at that port, then they are send raw gate events.

I have to think the load on PI would be much lighter than the same clients banging away at xxx/api/v1/monitor and which sends about many times the data required on a per event quad/gate event.

[NicoLoco]

I like the idea of the Pi multicasting the information.
I would be careful with UDP as there is no guarantee the packets will be received, and Wifi can be flaky, especially in an environment full of other 2.4GHz and 5.8GHz signals.

Maybe we could setup a system where the server multicasts the last 10 events periodically via UDP.
If a client realises he is missing some events (missing IDs), it can send a request to the server asking for all events starting from event number X. This request would be handled in TCP so we know the server will receive it, and the reply will be received too.

[SSPW]

I agree UDP is fire and forgot with no guarantees.

I think the only thing that should be guaranteed in the ERLT system is the PI actually has all the data and one master connection (a laptop of other that is the race admin portal). Any other system hanging off the PI, like a text to speech client is secondary and should be prioritized that way.

I race with a group that has 30 guys turn out. Lets say 20 try to listen using a client that is polling the normal monitoring api. Its going to bog down the PI. Sure there should only be 5-6 connected. But they aren't going to start and stop their connections. Its a bad scheme.

Alternative is a TCP server that client registers with transponder ID or all data. Then client then only gets event data they registered for. Client is simple. Server is more complicated.

WIFI default ERLT PI2 based build sucks!!! We tried it for 5-6 full days sessions. Tested macs, pc, and IOS and android clients. Connection reliability was horrible. Connection often would restore without rebooting the PI. We have abandoned it. We run a wired connection to our main laptop for 4 weeks. Zero issues with cable. Zero issues with the PI. Never have to reset the PI.

We wont be returning to PI based WIFI. We are considering putting a WAP in the system. WAP wired both the PI and laptop. Other clients then could connect on reliable WAP based WIFI.

I don't think UDP to individual transponder clients or bulk update clients is a bad thing. The only time UDP message is missed is when there is no network! With wired connection that is basically NEVER! Single broadcast for all SECONDARY clients leaves the PI unloaded.

I have working code, ie 2 Python scripts that implement UDP broadcasts. One scripts sit on the PI and polls the ERLT SQLLite database (not the web based monitor api). If it sees a change in either the race session or the sees any new transponder gate events (since the previous DB query), it broadcasts a UDP message with ONLY the updates. There no extra data, ie unchanged info sent!

I also have a Python client that runs on IOS and other platforms, that receives the UDP messages.

Its bullet proof in wired testing. Its equally reliable with a reliable wifi network.

This scheme is much more efficient on both ends!