riebl
Reduce Autotalks link layer dependency
The current Autotalk link layer of socktap depends a lot on the Autotalks SDK which also changes its API from time to time. Due do license restrictions we cannot even compile the Autotalks link layer as part of our CI. Thus, I would like to reduce the dependency on proprietary APIs in Vanetza. For example, we could move the Autotalks code to a separate binary which exposes the V2X radio interface via UNIX domain sockets. Only the helper binary would depend on the Autotalks API then.
The data structure passed over the UNIX domain socket might look like this:
struct UnixDomainSocketFrame
{
uint8_t addr_len = 6; /*< actually used bytes for source and destination addresses */
uint8_t source_addr[6];
uint8_t destination_addr[6];
uint16_t data_len = 0; /*< occupied bytes in data array */
uint8_t data[2048];
};
These fields are sufficient to replicate the existing features covered by EthernetHeader. The socktap application would connect as client to a "link layer server" which forwards the frame to the actual radio. It is up to the server to set radio specific parameters (ITS-G5, C-V2X, etc.). There may be multiple open server sockets for different purposes (different radios, different priorities, etc.).
Do you think we should add some more fields to the frame structure @khevessy?
Shouldn't be the priority also somehow parameter of the transmission? Frankly it is not clear to me how this and the other radio specific parameters are set in this architecture.
Right, priority might also be a field of the frame. I suggest to add a uint8_t user_priority interpreted according to 802.1D. The server can then map this priority to a suitable radio-specific parameter.
Parameters not included in the frame structure need to be decided and set by the server implementation, e.g. setting them to fixed values in the simplest case. Variations not covered by frame parameters could be covered by switching the domain socket. For example, there might be a socktap.its_g5.sock (backed by an ITS-G5 radio) and a socktap.cv2x.sock (C-V2X radio).
@riebl I started looking into this. Do you think it could be implemented using internet domain sockets instead of Unix domain ones? We would like to use this approach so that the implementation could be reused when Vanetza is running on a PC separately from the device. Also, this way I think that some code from tcp_link and udp_link could be reused.
Furthermore, I will rewrite our production application to also use this approach, only problem is DCC (CBR) measurement, I plan on using a separate socket for this as the measurement also needs the initialization code from the Autotalks API.
As for the implementation, my understanding is that the separate binary will be stored somewhere in this repository without the source code, right?
Edit: I have another question, what is the purpose of addr_len element, shouldn't both the source and destination address be always available? And when speaking about the structures, I was thinking - since for C-V2X there are two transmission modes, that I use, AD-HOC and SPS, if there should not be another parameter that determines between these two modes of transmission since I think it could potentially differ between the packets.
The problem with plain structs over IP sockets is that you need to make sure that both endpoints have the same memory layout (padding, alignment) and you need to define the encoded byte order. On Unix domain sockets you are safe in this regard.
I agree, CBR measurements can be added easily using a separate socket. In fact, we take a quite similar approach for cube-radio.
A pre-compiled binary for Autotalks would be great and reduce a lot of trouble, especially for beginners. Not sure yet where and how it should be hosted, though.
The addr_len is meant for C-V2X (for example), where the addresses (L2ID) occupy only 3 bytes. This length applies then for both, source_addr and destination_addr. With addr_len = 3 you would only consider the first 3 bytes of each address and ignore the remaining 3.
Do you have any details if and how SPS is used in combination with ETSI ITS? So far, I have only considered ad-hoc sockets. An alternative to an additional field could be (yet another) socket, at least when the SPS parameters are fixed.
Plain structs - well I think that possible solution would be to use protobuf similarly as you do it for cube-radio, what do you think? Or maybe simpler, if the structure was serialized manually per elements and macros from arpa/inet.h would be used for multi-byte elements, these problems shouldn't arise, right?
addr_len - right, I forgot about C-V2X addresses. But since the stack only supports MAC address abstraction, I was setting first 3 bytes from L2ID, the rest with 0x00 and then work with all the 6 bytes.
SPS - I have only basic understanding of this, but I thought that e.g. CAM messages should be transmitted over SPS due to their periodic nature. Not sure about correct settings of the socket as the periodicity is changing, and I did not find any definitive details in ETSI documents (maybe initialize 100 ms sending and when CAM period is slower, just not use some of the allocated slots). I don't think the usage is explicitly defined there and I have been also using ad-hoc sockets, but am not sure that it is a correct solution.
I agree, we can add quite simple serialize and deserialize functions which translate the struct into a platform independent wire format. The memory layout of structs is not fixed across platforms, so we should not use the struct as buffer directly.
Yes, one can also just fill up the rest with zeros. But one still needs to be careful with broadcast addresses then, which should be filled up with 0xff. Ultimately, Vanetza will get a proper C-V2X link layer.
I think SCTP would be a great fit for "remote sockets" because (in contrast to TCP) it has built-in frame delimitation and its stream concept would allow us to transport payloads and CBRs over a single connection. I made some quite good experience with SCTP in a completely unrelated project.
Could this be closed because of af9f5de? Guess the only thing missing is the helper binary that would expose the RPC server. The Autotalks code should be then removed completely?
Yes, I am going to remove the old Autotalks link layer implementation from socktap after some grace period. Meanwhile, we can add a link to your RPC server implementation to the documentation.