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.
> > When one would move from static to dynamic addressing, that means one is
> > forced
> > to use recvmsg() over recv() & recvfrom(), which looks to me as a way too
> > big constraint
> > (read: being forced is a big constraint).
> > given the small step you're taking. IMO, this proves the API being rude
> > to users of dynamic addressed busses.
>
> Sorry but i still wonder why recvfrom(), recvmsg() and sendto() are still that
> important for your API. Why not defining a uint64_t name for receive and one
> (different) uint64_t name for sending (with sockopts) and then just use read()
> wand write().
>
I see 4 'typical' use cases for the receive side:
1. _least important to base the api upon_: tracing: get every message, with
all whistles & bells.
I can do this via recvmsg() with extra cmsg's added (like timestamp)
2. application, communicating with 1 ECU, on 1 PGN (per socket).
I would support this totally via connect(), but an extra setsockopt
would work indeed. recv() or read() can be used then.
I think this is the use-case typically applied when using the isotp
protocol.
3. receiving several PGN's (masked or so) from a single ECU. example:
getting all info from a Engine Controller (single ECU, a dozen PGN's).
read() or recv() would not work in this case, as the PGN is not embedded
in the data. recvfrom() would work fine, since the supplied
sockaddr(_can) will get the SA & PGN.
so:
recvfrom(sock, buf, len, flags, &addr, sizeof(addr));
switch (addr.can_addr.j1939.pgn) {
case XXX:
break;
case YYY:
break;
}
4. more generic program: get a single PGN from different ECU's. example:
getting all DM1's (diagnostic message: active errors, 1 single
predefined PGN) from the bus, and
do something with the errors (like saving in a log, ....).
with recvfrom(), I would get the next DM1 received, together with the
source address spec (I get the PGN too).
so:
/* a dm1 message sends a series of 4byte date, 1 per SPN (sensor).
* each block of 4bytes thus specifies an SPN (id) and FMI (failure
* mode indicator, value).
* there are some more fields, but irrelevant for this demonstration.
*/
recvfrom(sock, buf, len, flags, &addr, sizeof(addr));
foreach(entry, (dm1*)buf) {
cached = lookup(entry->spn, addr->sa);
if (!cached) {
cached = malloc_and_add(entry->spn, entry->fmi, addr->sa);
save(cached);
} else if (cached->fmi != entry->fmi) {
cached->fmi = entry->fmi;
save(cached);
} else {
//nothing changed for this entry
}
}
Problem: this only works for static busses. for dynamic busses, the SA
is not persistent, so saving the data would be based on the 8byte name.
better is:
cached = lookup(entry->spn, addr->name, addr->sa);
&
cached = malloc_and_add(entry->spn, entry->fmi, addr->name, addr->sa);
as both name & sa may be add to unique-ness.
the options are:
lookup in a special proc file => transient problems
ioctl() like SO_TIMESTAMP, or getsockopt => transient problems.
putting the name in sockaddr => all problems fixed.
The above transient problem is related with the fact that the at the
time of lookup (or ioctl()), the mapping between 8byte name & 1byte
address may have changed. This greatly depends on the applied timing in
the user program, but the api 'should be hard to abuse'.
I keep in mind that the 8byte name does not need to be set, it's only
set when dynamic addressing was in place for that SA.
The simple logic would be that when 8byte name is != 0, it takes
precedence over the 1byte SA, on both tx & rx side.
When dynamic address is _never_ used, the name may be ignored. I don't
have a problem with that. I consider that an application choice on how
to use the API.
>
> Regards,
> Oliver
I hope this clarifies my use cases.
Regards,
Kurt
>
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
