Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Explain "non-reliable" in README.md #14

Open
Gdsimms opened this issue May 25, 2023 · 6 comments
Open

Documentation: Explain "non-reliable" in README.md #14

Gdsimms opened this issue May 25, 2023 · 6 comments

Comments

@Gdsimms
Copy link

Gdsimms commented May 25, 2023

The README.md file currently states "a shared, non-reliable bus" and this is scaring off some of my coworkers from adopting this as a solution to a current problem we have. Could you explain somewhere in the documentation what the meaning of "non-reliable" is in this context? Is it just that it can't prevent corruption when multiple devices send simultaneously? If that's all it is, then my other current issue #13 would make the bus reliable by locking out writing on all but one fake_tty.

@leoheck
Copy link

leoheck commented Nov 8, 2023

I was reading the README yesterday and this word also made me uncomfortable. What is the meaning of non-reliable here @Gdsimms ? Can you give us a hint on what you thought?

@Gdsimms
Copy link
Author

Gdsimms commented Nov 8, 2023

I have no answer. I have switched to using a few 'socat' commands to perform the serial sharing in my application.

@leoheck
Copy link

leoheck commented Nov 8, 2023

Ah, sorry I wanted to ask @danielinux , this MS GitHub is getting annoying.

@Gdsimms this is interesting, I was using socat since it is more spread. But a coworker asked me to change to use this instead. I will give a socat another try to compare it with ttybus

@danielinux
Copy link
Owner

non-reliable simply means that there is no guarantee that all the bytes are transferred to the destination, because the output is non-blocking.

Imagine a tty transmitting to two devices attached. If one of the two is not 'ready to receive' (i.e. poll with POLLWR returns 0) only the other one will receive the payload.

Perhaps instead of 'non-reliable' it would have been more correct to use 'best-effort'.

@leoheck
Copy link

leoheck commented Nov 10, 2023

I see, thanks for your feedback @danielinux

What about the data being transferred while both clients are connected and working. Can we say that both clients will always receive the same amount of data without losing any bytes?

I am splitting data from a gnss board connected to the USB into 2 instances of a server. It looks it works fine, but after a couple of hours or after a day something changes on one of the servers. I am not saying if ttybus is the issue, I just don't know where to look to find or debug this specific issue.

@OevreFlataeker
Copy link

I have no answer. I have switched to using a few 'socat' commands to perform the serial sharing in my application.

Could you please describe how you used socat to multiplex the access to the ttyUSBx device?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants