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

Server::Service trait has no mechanism to obtain request's unit ID in call implementation #96

Closed
fdlg opened this issue Aug 25, 2021 · 2 comments

Comments

@fdlg
Copy link

fdlg commented Aug 25, 2021

For an RTU server, it's important to know a request's unit ID when the devices are on a bus. For example, on an RS-485 bus, all devices will receive all requests but only the intended receipient should send a reply.

For a TCP server, knowing the request's unit ID allows implementing logical devices or the implementation of a gateway that forwards a request to an RTU device.

The rtu and tcp server implementation already have the unit id readily available in the Header struct that they get in a frame:

let hdr = request.hdr;
let response = service.call(request.pdu.0).await.map_err(Into::into)?;

let hdr = request.hdr;
let response = service.call(request.pdu.0).await.map_err(Into::into)?;

The first potential solution that comes to mind is modifying Server::Service::call's signature to this:

fn call(&self, slave: Slave, req: Self::Request) -> Self::Future;
@fdlg fdlg changed the title Server::Service trait has not mechanism to obtain request's unit ID from call implementation Server::Service trait has no mechanism to obtain request's unit ID from call implementation Aug 25, 2021
@fdlg fdlg changed the title Server::Service trait has no mechanism to obtain request's unit ID from call implementation Server::Service trait has no mechanism to obtain request's unit ID in call implementation Aug 25, 2021
@fdlg
Copy link
Author

fdlg commented Aug 26, 2021

I prototyped that change in the following PR in case it's something we want to do:
#97

@uklotzde
Copy link
Member

uklotzde commented Mar 4, 2023

Fixed by #141

@uklotzde uklotzde closed this as completed Mar 4, 2023
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

2 participants