APP-7128 support modules on windows

[abe-winter]

What changed

• high-level: support modules on windows by using TCP sockets instead of unix sockets
• added utils.ViamTCPSockets to control new 'tcp sockets mode'. this is always true on windows, can be forced with VIAM_TCP_SOCKETS env var
• when ViamTCPSockets is true:
  • Module.Start uses incrementing localhost ports instead of unix sockets on windows
  • in webService.StartModule, addr = "127.0.0.1:14998" instead of parent.sock
• disable ftdc on windows because it logs tracebacks; guessing this can be fixed as follow-up

Why

Windows support on non-WSL machines.

Checklist

• factor out windows detection to a util, allow it to be set behind VIAM_TCP_SOCKETS var as well
• run existing module unit tests in TCP mode

Follow-up

• fix ftdc on windows
• investigate unix sockets support on windows -- details in comments in ViamTCPSockets() function
• think about port collisions w/ other services -- simplest fix might be to allow users to configure the port range so if this does happen, it's simple to patch. Think about port exhaustion -- should reclaim ports when done. ideally, use system-assigned ports (but hard bc of how we generate them)

[cheukt]

has this been tested on a windows machine? also would definitely would want the followup to deal with port exhaustion and reclaming ports

[abe-winter]

Re testing, has been tested on Windows 10 with gps, wifi sensor, and viamboat modules. Modules require minor tweaking to get them to work: - go.mod replace rdk with this branch - change filename of executable to .exe extension

…

On Fri, Dec 13, 2024, 11:30 AM Cheuk ***@***.***> wrote: ***@***.**** commented on this pull request. has this been tested on a windows machine? also would definitely would want the followup to deal with port exhaustion and reclaming ports ------------------------------ In module/modmanager/manager.go <#4605 (comment)>: > @@ -1164,12 +1184,14 @@ func (m *module) startProcess( ) } } - err = modlib.CheckSocketOwner(m.addr) - if errors.Is(err, fs.ErrNotExist) { - continue - } - if err != nil { - return errors.WithMessage(err, "module startup failed") + if !rutils.TCPRegex.MatchString(m.addr) { leave a comment as to why we're skipping — Reply to this email directly, view it on GitHub <#4605 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXLTSZLDW5O6FM6W4W3U6L2FMDSPAVCNFSM6AAAAABTEGWS2WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMBQG4YTSMBWGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Otterverse]

Comments only for the moment. I'm nervous about opening up TCP.

[Otterverse]

What happens when a port is occupied?

[abe-winter]

when a port is occupied, this breaks; long term, we need a better way to do this. can potentially request an unused port (:0) and have module report to RDK via the parent socket, but that's more plumbing

[Otterverse]

What happens when this port is occupied?

[abe-winter]

TCP sockets support breaks

follow-ups ticket APP-7240 will change this to zero to auto-assign

[abe-winter]

@cheukt created APP-7240 for port exhaustion

[abe-winter]

@Otterverse

have you considred named pipes

yes -- planning to explore named pipes and unix sockets support as follow-up. best outcome would be for us to solve go-grpc support on windows AF_UNIX so that we can be completely stock