Use ip:port as client identificator

[jfriesse]

Currently it's not possible to run omping server and two clients from same IP. Main problem is, that client is identified only by IP address and not UDP IP:port.

This means, that rhlist must be changed to list of server info and list of clients info. List of clients info doesn't change much, but list of server info (about clients) must be dynamically expendable. This also means (because of memory reasons) to implement some kind of garbage collector which will free long time unused client info after some period of time (few minutes but should be tunable).

[Napsty]

From troglobit/omping#3

Yep, that explanation makes sense. But if I understand correctly, by using different ports (second server instance listening on another port, second client connecting to this port) this could be worked around? Or did I misunderstand this?

And to avoid that an unwanted client shoots down the master add an optional auth mechanism (kind of similar to what keepalived is doing)? I'm not a C programmer so it would take me two years to wrap my head around it but maybe you'd already know how to do this?

[jfriesse]

@Napsty Yep, second server instance would solve the problem, but it would be far from perfect - client would need to specify port and also what if there are two such clients running? Basically idea is to allow something like:

$ omping -O server local_ip &
$ omping -O client local_ip &
$ omping -O client local_ip &
...

running without any problem. This is impossible with current implementation.

auth mechanism (or encryption) is neat idea, but it is not defined in the rfc (https://tools.ietf.org/html/rfc6450), so it would need to be implementation specific addition. I'm not sure how exactly this is solved by keepalived, but RFC defines DOS protection in quite simple way - there is configurable maximum number of clients, timeout (so if client doesn't send request for timeout time it is disconnected), client and server id, and list of allowed ips/ranges.

Actually omping initial implementation was really designed to have a omping which behaves both as a client and server. I've implemented server mode just because it seemed to be easy ... and it turned out to be not so much true :)