Second transmission. the email got lost between me & lists.berlios.de On Wed, Mar 03, 2010 at 08:12:30AM +0000, Oliver Hartkopp wrote: > Kurt Van Dijck wrote: > > On Mon, Mar 01, 2010 at 10:41:00PM +0100, Oliver Hartkopp wrote: > >>> When this 8byte name is stripped from the sockaddr, > >>> this would work as sender (definitely), but would not work as good for > >>> receiving. > >>> An extra cmsg would work, but I doubt such API (for standard > >>> usage) is a good API. > > After reading your good and informative description, i would tend to propose Should have supplied it earlier :-). > this cmsg solluion. So far it's only necessary for use-case '4' which is not > common j1939 transport but comes from a special application requirement. * I doubt use-case '4' is 'special' only use-case '1' I consider special. * the sockaddr is not 'j1939 transport' related, but j1939 related (mind the difference). The j1939 stack I'm now working on mainly provides 2 features in-kernel: dynaddr & transport.
[...] > > Yes. That's true. But can be solved with cmsg. indeed. > > > When dynamic address is _never_ used, the name may be ignored. > > So then it's superfluous all the time. IMHO, IPv4 does similar when supplied 0.0.0.0 > > > I don't > > have a problem with that. I consider that an application choice on how > > to use the API. ... ie. choosing between static & dynamic addressing. > > It's up to _us_ to lead the user work with easy and hard to misuse APIs. > [...] > > There's no reason to overload the address structure with optional(!) data, in case of dynamic addressing, the j1939.addr member is unused too! The optional point is the choice between the 2 members, but in both cases will the other one be discarded. I agree to avoid overloading (stripped a lot yet), but I don't consider j1939.name as optional. it is required in at least 80% of my use. Although j1939 _was_ primary used with static addressing, most busses I encounter now are mixed, and dynaddr seems to increase (in my world at least). Maybe I'll describe the dynaddr in j1939 a bit by comparing with DHCP. DHCP is host based, ie. it concerns a single host (and a server). During the DHCP, the host is unreachable (no IP yet). After DHCP, the host has a 'fixed' IP. If the host would start a new DHCP request, it may get another IP (theoretically). From that point in time, the old IP is not assigned to that host. Any IP connections will get stalled, since DHCP was not a network or bus operation. dynamic addressing in j1939 differs on 1 important issue, in a way that address claiming is a bus operation. This allows/forces other members on the bus to update their name-address caches. Any j1939 member should still keep functioning, with the updated address in mind, ie. if I was listening to SA 0x80, which moved to 0x81, I'm supposed to transparently continue listening to 0x81. In theory, even a pending transport protocol session should move to the new SA (0x81), although I _suspect_ most implementations will just abort & retry. This can only be done by effectively do the listening based on 64bit name, and not the 8bit address. It would create a mess in a program. Therefore, my proposal is to ignore the SA completely at that point, and work with the name instead. > that need to be checked if != 0. Better send a cmsg entry with the name when I tend to evaluate static & dynamic addressing as equal choices. Requiring cmsg in case of dynamic addressing, makes this choice 'unequal', not _as_ straightforward. So, we (the API) lead the user into preferring static addressing. To illustrate this with the use-cases I provided, then '2' does require _other_ calls in order to make it dynaddr-capable than '3' & '4' do. > it needs to be. > > Would you be also fine with that in the case of dynamic addressing? Although there's no technical problem left, I hesitate to make that choice to the API. If it's ok, I'd like move away from pure technical issues, and inspect the API as such. see also the difference with DHCP above. Since I didn't convince my management of open-sourcing all yet, there's no hurry anyway. IMHO, your proposal violates these 2 major points you mentioned earlier with API design (with special regard to dynamic addressing, since static addressing will does not suffer this): * Easy to learn * Easy to use, even without documentation. I think I would prefer documenting that 'name == 0 means static addressing used'. We coud so reduce the application choice between static & dynamic addressing to just choosing between j1939.name & j1939.addr, rather than choosing between API calls. Yes, this choice can be made wrong. When j1939.name is set, but not used, users might experience problems. I bet this will occur much sooner if they would need to get the name elsewhere (via cmsg()). The biggest challenge with documenting this j1939 approach IMO is learn typical CAN/J1939 users to think in terms of local & remote addresses in a BSD socket compliant way, rather than combining local & remote address in 1 can_id (as I also did when I started 10 years ago, I'm not blaming anyone here). The dynamic thing is minor challenge in documenting the api, given that using it is not too difficult. > > Regards, > Oliver Regards, Kurt > _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
