Get status of transmission?
pylessard opened this issue · 7 comments
Hi
I guess this question applies to sockets in general, but I figured I'd ask here anyway.
Is there a way to get a status of the transmission after writing to the socket? The goal would be to know if the last frames has been sent.
The rationale behind this is that UDS protocol has some reply timeout values defined and they appear to be relative to the moment a request has been completely sent. For large request, it can takes seconds to get the whole payload transmitted. If I want to check the timeout correctly, I have to start counting from the end of that delay, not from the moment I write to the socket.
Any idea how this could be handled with your module?
Maybe implementing an ioctl for SIOCOUTQ or SIOCOUTQNSD ?
Hm. Would this mean you need to poll with tons of ioctl() syscalls to check, when the PDU has been sent entirely??
Today the next (second) write access to the socket blocks the process until the former transmission has been completed. There is just a single PDU buffer for transmission.
What about blocking even the first write syscall until the PDU has been sent out?
We would then still have one buffer but the process would be blocked until the PDU is sent completely.
That would mean polling, yes. I am comfortable with this given that I don't need a fine granularity.
I am not sure about blocking at write time. Wouldn't that cause problem for full duplex operation?
Are you saying that I could write a 0 length payload to the socket and the success of this operation would confirm that my previous payload is completely out?
In term of ISO-15765-2. This feature would correspond to providing N_USData.confirm. Actually, it would be ideal to detect the beginning of a reception through N_USData.FF.ind. The UDS P2 timer is relative to the end of transmission and beginning of reception. If N_USData.FF.ind is not available (sart of reception), ISO-14229-2 suggest to time between end of transmission and end of reception (P6 timer).
My actual implementation count between start of transmission and end of reception.
The N_USData.confirm service is issued by the network layer. The service primitive confirms the completion
of an N_USData.request service identified by the address information in N_SA, N_TA, N_TAtype [and N_AE].
The parameter <N_Result> provides the status of the service request (see 7.3 for parameter definition).
I was checking out some more documentation about sockets. And in fact sockets are usually blocking. So if we would block the write() syscall until the PDU is sent, this would be correct.
The programmer would be able to set the socket into a NON-BLOCKING mode, where you get an -EWOULDBLOCK error, when the buffer is not free (== the PDU is not sent).
This can be handles with poll() or better select() to monitor the sending socket.
The question whether you are losing the full-duplex capability:
- UDS is a half-duplex protocol, right?
- if you use select() you have separate 'watchers' for read/write even on the same file descriptor
So the select() call would either return when you received a PDU or when the writing filedescriptor signals to be writable again.
I wonder if it would make sense to create a "standard conform" blocking version of the current implementation to play with select() and see if it fits the needs?!?
Hi,
- UDS is mainly hald duplex, except for some services that can send payloads on event. I don't support these services anyway. My reasoning stopped at the transport layer level, ISO-15765 is full duplex by definition (I think).
- Would probably work.
I think it would make sense to try the blocking version of the module. No rush.
Addressed here pylessard/python-udsoncan#43 (comment)
and hopefully closed ;-)