Kurt Van Dijck wrote:
> On Sat, Feb 27, 2010 at 07:26:46PM +0100, Oliver Hartkopp wrote:
>> Btw. dynamic addressing is not an *essential* functionality for all J1939
>> applications, that only like to communicate using J1939 protocols, right?
> Ack.
Fine.
>> Having
>>
>> struct {
>> uint8_t sa, da;
>> uint8_t priority;
>> uint32_t pgn;
>> } j1939;
> 1. during this discussion, I learned that combining source & destination
> in 1 sockaddr is bad. I turned my code into a seperate source &
> destination, with only PGN duplicated. It avoids some other confusion,
> like which fields are used/filled out in: bind(), connect(),
> recvfrom(), sendto()
> 2. To know the exact destination address of an incoming message, I added
> a sockopt to add the original destination sockaddr into a cmsg.
> so, a recvfrom(), you must suppose you're a receiver, but don't know
> if it were a broadcast or not. with recvmsg(), you can find out.
> 3. Since priority is an option, I turned that into a sockopt
> (potentially reusing the existing SO_PRIORITY option). for receiving,
> the priority is only usefull in debugging, and I put it into a cmsg
> entry in recvmsg().
> (1), (2) & (3) lead to
> struct {
> uint8_t addr;
> uint32_t pgn;
> } j1939;
> which is very clean.
Yep - very nice.
> I know most j1939 users will ask where the DA has gone, but existing
> socket API's have different structs for source & destination.
>
> To come to this stripped version, a few cmsg entries are added to allow
> debugging tools get all information, but those entries are IMO not used
> in everyday communication.
> Some socketoptions will be used in everyday applications, but that does
> not make the code (using a j1939 socket) much more complex.
>
>> and
>>
>> uint64_t name;
>>
>> in /one/ structure IMO could lead to confusion and therefore to potential
>> misusage.
> would
> struct sockaddr_can {
> union {
> struct {
> uint8_t addr;
> uint32_t pgn;
> } j1939;
> struct {
> uint8_t addr;
> uint32_t pgn;
> uint64_t name;
> } j1939_dyn;
> } can_addr;
> };
> make things better then? IMO not.
Indeed no :-)
My suggestion was to the the uint64_t name only via setsockopt to identify
dynamic adressing.
> 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().
Won't this work fine for the user?
Regards,
Oliver
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
