On wo, 26 jun 2019 16:02:38 +0200, David Jander wrote: > > > > On di, 25 jun 2019 10:54:55 +0200, Oleksij Rempel wrote: > > > > > On 25.06.19 10:43, David Jander wrote: > > > > > >On Tue, 25 Jun 2019 09:30:09 +0200 > > > > > >Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > > >>Hello all, > > > > > >> > > > > > >>We already had a discussion about the J1939 use case for server > > > > > >>implementation. Short description of the challenge will looks as follow: > > > > > >>- main socket is listening on DST address and PGN. > > > > > >>- as soon as connection was requested from peer the server will > > > > > >> create new connect()ed socket with SRC, DST addresses and PGN. > > > > > >> > > > > > >>With current stack implementation both sockets (main and connected) will > > > > > >>receive same packages. At least with huge packages it will start to be > > > > > >>not really good :). > > > > > >> > > > > > >>To solve this issue we have following variants: > > > > > >>variant a: > > > > > >> - all sockets can receive everything (as currently implemented) > > > > > >>variant b: > > > > > >> - only one socket will receive specific tuple. In this case kernel > > > > > >> should calculate RX "priority". Only highest priority will RX packet. > > > > > >> - all sockets with same priority will receive the matching packet > > > > > >> - socket option promisc == same priority as exact match [...] > > > > > > > > I don't like any of these. > > > > > > > > The problem you try to solve is 'huge packet duplication where it is > > > > probably not required'. > > > > Your proposed solution puts a policy in the kernel that goes in serious > > > > conflict with a multiuser system. It is driven by a typical > > > > implementation, but did not address the problem you try to solve. > > > > > > > > In order to avoid receiving huge packets where we suspect it is not > > > > really wanted, we should not try to guess what 'a' program wants, nor > > > > implement rules that apply to 1 specific case. > > > > Instead, we should protect sockets from receiving huge packets. > > > > > > > > Why not add a socket option, that implements a ceiling on the > > > > size of received packets. > > > > If that defaults to, let's say, 1785 bytes, so anyone will out of the > > > > box receive all TP sessions, but no ETP session, then the user will not > > > > be really supprised, and we need to make only 1 clear decision during delivery. > > > > > > > > I honestly think that my proprosal puts way less decision policy in the > > > > kernel code, and effectively addresses the problem you tried to solve, > > > > without adding unnecessary multi-user restrictions. > > > > > > > > What's your thought? > > > > > > Thanks for your feedback. I understand it may sound counter-intuitive, but it > > > really isn't. What we are trying to accomplish is for SocketCAN with J1939 to > > > behave much like a network adapter with TCP/IP. > > > > J1939 is a datagram system, so more like UDP/IP. > > In some aspects it is more like UDP, but unlike UDP, J1939 does have have > handshaking (in hardware) and is considered reliable. > Also the transport protocol implements handshakes and reliability for bigger > "datagrams". There is no handshaking, and by far not in hardware. The only handshaking that exists is for non-broadcast TP. Broadcast TP and <=8byte datagrams are sent unreliably, just as regular CAN. > On top of that, many applications (like the ISObus fileserver, or the ISObus > VT) behave much more like a connection-oriented server, thus benefiting more > from the TCP/IP server analogy. I.e. there is a "client" who establishes a > connection with a "server" and from then on they semantically communicate over > a point to point channel, akin to a connected TCP/IP socket. If you create a server where different sockets are used for different DST+PGNs, and you want to avoid receiving the same thing in your own sockets, then you should be more precise in your applied filters. Unlike TCP and UDP, most J1939 applications are not designed with 1 or few PGNs in mind, but use a huge range of PGN's. That is why filter lists are common in CAN / J1939 and not in TCP / UDP. The 'server' example is the exception, not the standard. > True. But like I said above, in ISObus there are use-cases where a > connection-oriented approach is used, even though there is no formal > handshaking of the establishment and closing of a connection in the link layer. A 'server' socket that 'listens' for new 'connections' need not listening to all PGNs, does it? IMHO, it needs 1 or a few PGNs, and the point-to-point socket needs the rest. So, worst cast, the point-to-point socket receives also the packets that trigger connection construction/destruction for 1 specific destination, and more specifically, it needs those in order to close your virtual 'connection'. If this is not feasible, then adapt your listening socket's filters accordingly. > > I'm not aware of the complexity that has been added recently for the > > ETP, but that should not break multiuser operation, i.e., > > if I write 'a' program, then that program should receive the same thing > > regardless of the presence of other sockets on the local system, with or > > withing the same process. > > I would not plan to violate that rule. > > I seriously would not. > > That rule is not violated as long as these processes have their own address > (and NAME). If they share the same address and NAME, they are part of the same > control-function. In that case, as long as they do not connect() and only use > sendto() and recvfrom() that rule also holds true. > It is only when you use connect() to establish a 1:1 connection with another > peer. The only difference with TCP/IP sockets in that case is that you use > connect() on both ends instead of listen()/accept(), and the > establishment/tear-down of the connection is thus left to the application. Then you must redesign/redefine the filters because they are no more coherent. Kind regards, Kurt
