On Fri, Feb 26, 2010 at 10:50:00AM +0100, Oliver Hartkopp wrote: > Date: Fri, 26 Feb 2010 10:50:00 +0100 > Kurt Van Dijck wrote: > > On Fri, Feb 26, 2010 at 08:58:45AM +0100, Oliver Hartkopp wrote: > >>>> Kurt says: > >>>> * bind() will assign local address. > >>>> * connect() assigns destination address. > >> Would this be a "write only" socket then? IMO "connect" also requires the > >> local address. > > Yes, since connect() only sets the destination address, no local address > > has been set, unless bind() is issued. > > That looks unusual. > > connect() is for "connected" (like TCP) and bind() for "connectionless" > protocols. > > Maybe connect is completely wrong in J1939 contexts. I studied the man pages on this topic: man 2 connect If the socket sockfd is of type SOCK_DGRAM then serv_addr is the address to which datagrams are sent by default, and the only address from which datagrams are received. > > > To make the API easier, I'd think it's usefull to have the kernel take > > the first 'local address assigned' when local address is missing at the > > time of send. > > IMO, bind() should not be necessary for receiving too. > > You should probably use the special SA/DA values to indicate broadcast > addresses. I'm not sure I understand. Do you mean: use 0xff as SA to indicate to the kernel to take the default? that is how I implemented now. > > > >>>> * We want to extend the j1939 bus into the > >>>> linux kernel, so different sockets can be logically different > >>>> entities, just as can_raw does for can. > >> What is an entity here? > > I tried to avoid using J1939 specific terms, but here it goes. > > J1939 talks about ECU (electronic control module) that claims a single > > SA. an ECU may be regarded as a single controller on the CAN bus, but a > > single controller may implement several (virtual) ECU's too. > >> A socket is a communication endpoint that can hold e.g. a communication > >> relation from a local address to a specific destination address. > > But virtual ECUs distinguish from SA, right? yep. > Then it's not 'visible' in the concept. ?? [...] > > >>>> > >>>> At the next level, j1939 describes a dynamic addressing scheme (the > >>>> above is working fine with static addresses only). That's especially > >>>> used a lot in agriculture (our main market). > >>>> At that point, SA & DA are not persistent anymore, but the 8byte name > >>>> is. > >>>> We intent not to let kernel code participate in this dynamic > >>>> addressing, > >>>> but let the kernel code follow the actions on the bus. Since a single > >>>> instance must decide which name an SA belongs to & vice versa, the > >>>> kernel is the perfect place. > >> No. > >> > >> I checked the idea of the Dynamic Address Configuration in SAE J1939 here > >> > >> http://www.can-wiki.info/SaeJ1939 > >> > >> and this is definitely something that has to be handled outside the kernel. > > Like I mentioned, the actions are taken in userspace, but the kernel > > should track when a SA is valid and when not. > > And when it's not - what happens? good question. when dynamic addressing is used, then during the address claim 'dead time' the j1939 spec says it's illegal to send other stuff with that SA. So, if such packet comes in, it _should_ be dropped/ignored. > Is the socket collapsing after sending a socket error? collapsing? I don't understand the word. > > So far i cannot see a value in putting the name into the kernel. When the 2 packets from the same ECU may arrive. a regular socket user must be able to recognize them as coming from the same ECU. therefore, instead of relying on the SA, in dynamic addressing environments, such user should rely on the name. sending a packet to a particular ECU has the same issue. the same SA does not necessarily address the same ECU. To avoid delay problems, the mapping name->SA is done in kernel, in a very late stage. But the kernel needs the names then. > address becomes invalid the application needs to be informed to close and/or > re-initialize it's connections. E.g. with signals or from the (already planned > daemon). When an SA becomes invalid, the daemon has some time to claim a new. It is legal to change address, and I would not generate errors on legal actions. Only when address becomes invalid indefinitely, an error should be generated. It is not the daemons job to inform other sockets about such things, it's the kernel's job IMHO. The daemon's job is to find valid addresses & claim them as much as possible. nothing more, nothing less. The kernel's job is to keep the name-SA assignements and respect timing. the kernel should never claim addresses from its own. > > Like this one: > > >> Better write a daemon and/or library for that like for DNS in IP. > > ack, 1 daemon per SA or so was our plan > [...] > > When a user want j1939 communication, he/she should be able to just open > > the socket, do bind()/connect() as he/she pleases, and start sending. > > A common mistake when using j1939 (at least I found that) is to deal > > with CAN raw messages instead of j1939 packets. This works like a brake > > on applications. One should be able to ignore the actual CAN raw > > messages, and work with J1939 packets instead. > > The J1939 (sockets) just give you a different view on the CAN, where the world ack. > is good and the sun is shining. Mmmmh. > > Who want's to use can-raw in J1939 environments then? that's like asking: who want's to use ethernet in IP environments? It's not forbidden. But sticking to j1939 keeps you from mistakes against the j1939 protocol. > > And that your 'DNS' daemon probably uses can-raw is hidden from the users ;-) That is an option, but I don't see the benefit yet. If I see benefit from this, I won't hesitate to do so. > > Finally (even if i do not like it) a socketoption containing the 64 bit name > can be placed into the socket as soon as it is created. Before or after bind() > is irrelevant. for outgoing packets, that could be done. and for incoming, one could create an extra ioctl. but, it deviates from existing API's in a way I don't like. Such API would suggest the SA in the sockaddr is reliable, which is not always the case. To know that, an extra getsockopt or ioctl is needed. bind(), connect(), recvfrom() & sendto() all benefit from a proper sockaddr _with_ the 64bit name.
I would not confuse my users by putting it elsewhere, when it's not appropriate. I don't like it too. > > Regards, > Oliver I feel that apart from dynamic addressing, we pretty much agree on everything :-). May I state this ?: Doing proper dynamic addressing across several sockets/processes needs a limited kernel knowledge. I don't contest the kernel's effort should be minimal. Without kernel support, there are some mistakes that cannot be avoided (and those mistakes are common, I can assure you). To let the kernel do it's minimal action, userspace communication must be done with 64bit names instead of 8bit addr. Whether or not the 64bit name is added in the sockaddr decides on being capable to do proper dynamic addressing, or leaving transient problems in it's dynamic characteristic. > regards, Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
