feat: introduce serial link recovery

[sansmoraxz]

Attempt protection against shoddy wires in RTU connection.

Fixes: #122

[alexjoedt]

Hey, sorry for the late review! Really like the direction here.

I left a few comments, mostly around defaults and some small robustness things. Hope they're helpful, let me know what you think!

[sansmoraxz]

Also this has the unexpected surprise of writing to currently open terminals.

modbus/Makefile

Lines 12 to 16 in 79617db

	test:
	diagslave -m tcp -p 5020 & diagslave -m enc -p 5021 & go test -run TCP -v $(shell glide nv)
	socat -d -d pty,raw,echo=0 pty,raw,echo=0 & diagslave -m rtu /dev/pts/1 & go test -run RTU -v $(shell glide nv)
	socat -d -d pty,raw,echo=0 pty,raw,echo=0 & diagslave -m ascii /dev/pts/3 & go test -run ASCII -v $(shell glide nv)
	go test -v -count=1 github.com/grid-x/modbus/cmd/modbus-cli

IMO instead of pts terminals perhaps better to have some tmp file that's auto trapped and deleted once tests are run.

[alexjoedt]

The connDeadline is captured once before the retry loop. After a successful reconnect() the remaining time on that deadline may be close to zero, causing readIncrementally (or readASCII) to time out immediately on the very next iteration and return context.DeadlineExceeded, which shouldRecover won't handle. This effectively makes link recovery useless under any real latency.

Please move connDeadline := time.Now().Add(mb.Timeout) inside the for loop (or reset it after a succesful reconnect), consistent with how tcpclient.go refreshes the deadline via SetDeadline on each iteration. Same issue exists in both rtuclient.go and asciiclient.go

[sansmoraxz]

Wait wouldn't this apply to linkRecoveryDeadline too?

[sansmoraxz]

Or there's a risk of infinite block

[sansmoraxz]

Yeah deadlock seems likely with incremental linkRecoveryDeadline.

We should probably mention somewhere that timeout is per read/write attempt instead of across the entire cycle as I was previously assuming.

The Timeout is coming from serial.

https://github.com/grid-x/serial/blob/ad4f461b8ed5860433b53666ddd6514cc83e0a95/serial.go#L30-L31

[sansmoraxz]

@alexjoedt where should it be documented?

[alexjoedt]

On the field itself?

[alexjoedt]

When a USB-serial adapter is physically unplugged mid-transfer, port.Close() can
itself return an error (e.g. ENODEV on Linux). The current code:

if cerr := mb.close(); cerr != nil {
    mb.logf("modbus: error closing connection: %v", cerr)
    return cerr   // <-- bails here
}

…returns immediately without calling connect(). Note however that close() does
set mb.port = nil even on error, so a subsequent connect() call would attempt to
reopen the device — exactly what recovery is supposed to do.

Returning the close error defeats the whole purpose of link recovery in the most common
real-world scenario (hot-unplug of USB-serial dongles).

What do you think to log the close error and continue to connect?

if cerr := mb.close(); cerr != nil {
    mb.logf("modbus: error closing connection: %v", cerr)
    // mb.port is nil after close(); still attempt to reopen.
}
if cerr := mb.connect(ctx); cerr != nil {
    mb.logf("modbus: error reconnecting: %v", cerr)
    return cerr
}

[sansmoraxz]

Returning the close error defeats the whole purpose of link recovery in the most common
real-world scenario (hot-unplug of USB-serial dongles).

Good point. Although I am not familiar with any program that does this. Most often they treat it as final error state.

I am a bit confused here, let's say close failed.

if cerr := mb.close(); cerr != nil {
    mb.logf("modbus: error closing connection: %v", cerr)
    // mb.port is nil after close(); still attempt to reopen.
}
if cerr := mb.connect(ctx); cerr != nil { // <- may fail due to timing
    mb.logf("modbus: error reconnecting: %v", cerr)
    return cerr
}

we keep spinning?

[sansmoraxz]

OK keeping spin, both for close and connect fails