There is a shm memory leak because the data is not allocated along with the evapi_relay_cmd structure. Also, the indentation seems to be done with whitespaces instead of tabs, breaking the formatting of the blocks. Thinking more of it, I think it could be rather hard to match on source IP and port for tcp connections, because the kernel may allocate random ports, even one tries to bind on a specific one. Maybe we can add sort of connection tagging (or channel name) - when the connection is open by the client app, it gives the tag/channel name. Or eventually, a new function can be exported to set the tag/channel name inside the event_route[evapi:connection-new]. The tag/channel name will be a new field in the connection structure. Then the evapi relay will match on this name rather than source ip port. What do you think? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/596#issuecomment-216663484

If you get the IP:PORT in event route, then you can also set the tag there and can be inside the evapi connection structure, no need for htable anymore. You need to keep the relation of the IP:PORT and service somewhere, same can be done also with the tag name and service. The benefit is that the tagging allows two or more connections to be tagged with same name and then send the message to all of these ones. Practically, more granularity, allowing to send to one, many and all. Also, at some point one may want to add transport as a constraint there, not only the address and port. You indented now everything there, apparently there was other code not indented with tags, but now the patch looks bigger. For the new structure, the data field can be str, not pointer to it, because it is all in memory. Also, all should be allocated at once, like it was before, making easier to deallocate and simplify the code in the evapi side. Anyhow, I will add the support for tagging and get the framework with a data structure, you can then add support for ip:port if you need specific this case -- I am fine with that. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/596#issuecomment-217374772

Hi Eloy, I added the framework for tagging connections to simplify the development of further extensions via sending a structure packaged at once. I haven't extended the config functions for evapi relay, because I thought we may need to decide on naming. We can add a second parameter for the tags in evapi_*relay() or we can add a new pair of functions: evapi_relay_multicast(data, tag), plus the one for async. Then, if you want to filter by ip:port, then evapi_relay_unicast(data, ip, port) can be added. Even when sticking to tags only, could make sense to have evapi_relay_unicast(data, tag) which stops after matching first tag. The multicast is walking to all connections to see if the tag matches. This unicast/multicast can be a new field in evapi_msg_t as an integer, so it won't need any speciall allocation to pass to evapi workers. What do you think? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/596#issuecomment-217393993

Right now there is one tag per connection support -- you can extend it if you need more, as well as rpc commands to control connections. You can add timestamp per connection and have further rules to select it for a unicast. I pushed cfg multicast functions. I let testing (and unicast implementation if you want it) for you. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/596#issuecomment-217406766

Thanks! --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/596#issuecomment-217612812