net/write on Windows throws unexpected network error

[rapidpunch]

The example in the Janet Docs, Networking, TCP, Clients

(with [conn (net/connect "127.0.0.1" "8000" :stream)]
  (printf "Connected to %q!" conn)
  (:write conn "Echo...")
  # ...
  )

causes an "unexpected network error" when executed on Windows:

error:
in net/write [src/core/net.c] on line 907

Substituting net/write with ev/write yields the same error, just shifting its source:

error:
in ev/write [src/core/ev.c] on line 3190

On Linux, everything works fine.

[bakpakin]

This works correctly on my machine with the latest master. I am using .\janet.exe examples\echoserve.janet in one command window and .\janet.exe examples\echoclient.janet in another window.

Is it possibly related to your firewall configuration?

[rapidpunch]

Interesting, those examples work fine for me on Windows as well.
So the problem's probably not the firewall.

What doesn't work on Windows is actually this:

(with [conn (net/connect "192.168.172.221" 8100)]
  (:write conn "SID?")

where 192.168.172.221:8100 addresses a service that knows how to respond to "SID?" -- again, this works fine on Linux.
When I change this to

(with [conn (net/connect "127.0.0.1" 8000)]
  (:write conn "SID?")

then this also throws an "unexpected network error" on Windows, but a "connection refused" error on Linux (which makes sense since there's nobody listening on the other side).
My suspicion is that the underlying functions of libev may behave differently under Windows.

[bakpakin]

We do not use libev so that isn't it. Please provide a reproduction script of some kind since I can't tell what is wrong from your description. Without more detail or an explanation of what the server and client are, it very difficult to say what's wrong.

[wmealing]

There are a number of security apps which hook into read and write calls on windows. I think that some of the corp versions of windows defender will also prevent read/write on sockets if it uses a similar configuration to known malware. These security apps should report behavioral violations in windows event log when it detects what it considers 'bad behavior'.

For anyone following along, sometimes changing the port to a higher random port number is enough to overcome these issues. Other times the problem may be that the program was executed from a common malware directory (C:\Temp) etc.

Leaving this here in case it helps someone in the future.