mbus-network 0.6.0

Provides network transport layer functionalities for modbus-rs project
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117

# mbus-network

`mbus-network` is a helper crate for [modbus-rs](https://crates.io/crates/modbus-rs).

It provides a standard Modbus TCP transport implementation that plugs into the
shared transport abstractions from `mbus-core`.

If you want a single top-level API, use `modbus-rs`.
If you need direct transport-level control, use `mbus-network` directly.

## Helper Crate Role

`mbus-network` is transport-focused and intentionally small:

- Implements `Transport` from `mbus-core` using `std::net::TcpStream`.
- Handles connection setup, send, receive, and disconnect for Modbus TCP.
- Maps I/O failures into `TransportError`.

This crate does not implement request orchestration or function-code services.
That logic is provided by `mbus-client`.

## What Is Included

- `StdTcpTransport`: concrete transport implementation for Modbus TCP.
- Timeout setup from `ModbusTcpConfig`.
- Basic DNS resolution and connect flow.
- Non-blocking receive pass that returns currently available bytes.

## Public API Surface

The crate currently re-exports:

- `StdTcpTransport`

from:

- `management::std_transport`

## Usage

### 1) Add dependencies

```toml
[dependencies]
modbus-rs = "0.6.0"
```

### 2) Create TCP config and connect transport

```rust
use modbus_rs::{MbusError, ModbusConfig, ModbusTcpConfig, StdTcpTransport, Transport};

fn connect_tcp() -> Result<(), MbusError> {
		let config = ModbusConfig::Tcp(ModbusTcpConfig::new("127.0.0.1", 502)?);

		let mut transport = StdTcpTransport::new();
		transport.connect(&config)?;

		// send/recv calls are typically driven by higher-level client logic

		transport.disconnect()?;
		Ok(())
}
```

## Configuration Notes

- Use `ModbusConfig::Tcp(...)` when calling `connect`.
	Passing a serial config returns a transport configuration error.
- `connection_timeout_ms` and `response_timeout_ms` from `ModbusTcpConfig` are
	applied to the underlying stream.

## Logging

`mbus-network` supports optional logging via the `log` facade.

- Enable feature: `logging`
- This only emits through the facade; your application provides a logger backend.

Example dependency setup:

```toml
[dependencies]
mbus-network = { version = "0.6.0", features = ["logging"] }
env_logger = "0.11"
```

## Receive Behavior

- `recv()` returns bytes currently available from the socket.
- A full Modbus ADU may arrive in multiple chunks.
- Higher-level logic should buffer and frame messages as needed.

## Typical Integration Pattern

In most applications, `mbus-network` is used together with `mbus-client`:

1. Build `ModbusConfig::Tcp(...)`.
2. Instantiate `StdTcpTransport`.
3. Pass transport into `ClientServices` from `mbus-client`.
4. Use client services to issue function-code operations.

## License

Copyright (C) 2025 Raghava Challari

This project is currently licensed under GNU GPL v3.0.
See [LICENSE](../LICENSE) for details.

This crate is licensed under GPLv3. If you require a commercial license to use this crate in a proprietary project, please contact [ch.raghava44@gmail.com](mailto:ch.raghava44@gmail.com) to purchase a license.

## Contact

For questions or support:

- Name: Raghava Ch
- Email: [ch.raghava44@gmail.com](mailto:ch.raghava44@gmail.com)