Are you missing documentation to any part of this package? Please describe.
I'm trying to understand what the idiomatic/recommended approach is for listening on multiple physical addresses.
Describe the solution you'd like
My use case is emulating multiple devices (in the context of being a UDS server) on a bus in a simple and low-volume way: I don't have a need (inherently) to run multiple processes or threads. It would satisfy my needs if I could have a transport that could specify multiple devices/physical addresses: device A receives at CD and sends from DC, device B receives at EF and sends from FE, and so on. Ideally, messages would then include this information so that I could use a unified chunk of code for generating the relevant response, knowing which address the request was received on and the address to send the response as.
Describe alternatives you've considered
It seems like my ideal solution isn't likely to line up with intended API usage, so I recognize that I might just need to spawn multiple handler threads, with dedicated transports, and so on. I figured it was worth asking to see if this use case had come up before and/or if you had thoughts of tackling this sort of thing. :)
Are you missing documentation to any part of this package? Please describe.
I'm trying to understand what the idiomatic/recommended approach is for listening on multiple physical addresses.
Describe the solution you'd like
My use case is emulating multiple devices (in the context of being a UDS server) on a bus in a simple and low-volume way: I don't have a need (inherently) to run multiple processes or threads. It would satisfy my needs if I could have a transport that could specify multiple devices/physical addresses: device A receives at CD and sends from DC, device B receives at EF and sends from FE, and so on. Ideally, messages would then include this information so that I could use a unified chunk of code for generating the relevant response, knowing which address the request was received on and the address to send the response as.
Describe alternatives you've considered
It seems like my ideal solution isn't likely to line up with intended API usage, so I recognize that I might just need to spawn multiple handler threads, with dedicated transports, and so on. I figured it was worth asking to see if this use case had come up before and/or if you had thoughts of tackling this sort of thing. :)