On do, 27 jun 2019 12:59:01 +0200, Oleksij Rempel wrote: > On Thu, Jun 27, 2019 at 11:33:53AM +0200, Kurt Van Dijck wrote: > For David's use case you want to receive the initial message by the > client, the you create a new socket()/bind()/connect() it. While the > newly created socket is active, you don't want to receive any messages > from that client on the server socket. This might be done by modifying > the filters. As soon as you close the dedicated client socket, you have > to modify the filers again. These are two separate operations, thus > racy by design. If you do it right, you don't loose any messages, but > receive them in both sockets. (Which makes user space handling more > complex). > [...] > We'd like to have an API that supports the whole spectrum of use cases. ack > > If this is not feasible, then adapt your listening socket's filters > > accordingly. > > I don't like this, due to the raciness of the approach. > > > > We just prototyped a sock option for "server" sockets. The options is > disabled by default, when enabled all packets that are received in a > connect()ed socket are ignored on this socket. Doing so applies the (IMO) broken semantics not by default, but the semantics remain broken until you can restrict the pool of sockets being evaluated for the server option to your own connection sockets. Looking at all requirements, you want to tell the kernel that it should divert delivery of a limited set of SRC/PGN/DST combination to another socket of yours. How about: setsockopt(ocnnsock, SO_J1939_SET_FILTERS, ...) setsockopt(connsock, SO_J1939_DIVERT_FILTERS, &srvsock, sizeof(srvsock)); connect(connsock, ...) This allows to maintain a list of related sockets to the server to evaulate for packet reception. I have no idea how to implement though. Kind regards, Kurt
