Get status of transmission? about can-isotp HOT 7 CLOSED

Maybe implementing an ioctl for SIOCOUTQ or SIOCOUTQNSD ?

from can-isotp.

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.

from can-isotp.

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?

from can-isotp.

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).

from can-isotp.

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:

1. UDS is a half-duplex protocol, right?
2. 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?!?

from can-isotp.

Hi,

1. 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).
2. Would probably work.

I think it would make sense to try the blocking version of the module. No rush.

from can-isotp.

Addressed here pylessard/python-udsoncan#43 (comment)
and hopefully closed ;-)

from can-isotp.