The only way I can replicate your issue is on 32-bit ahk. 64-bit works fine. Maybe i got some offsets wrong somewhere. I'm looking into it.
EDIT:
My first x64 test worked fine, but now I'm getting the error on x64 also. It's just a 0 length buffer. Which makes sense to throw such an error. I'm still trying to figure out why the read event reads 0 bytes.
There is also no error data at all in the coming from winsock, so this technically isn't an issue. It looks like I just didn't write in any means to handle a receive event that reads zero bytes. I'm still trying to figure out a case where zero bytes is sent, and what in general causes it.
@viv
I think I found the issue. This little socket lib is setup to be 100% async. But you are not the first person i've seen trying to use it as "blocking" at the "connect" phase, which does make sense to have such an option.
So the issue comes down to timing. This actually "fixes" the issue:
Code: Select all
test_send()
{
sock := winsock("client", cb, "IPV4")
sock.Connect("127.0.0.1", 27015)
sleep 1000 ; <------------------------- gotta pause, then send
msg := "abc"
strbuf := Buffer(StrLen(msg) * 3)
StrPut(msg, strbuf, "UTF-8")
sock.Send(strbuf)
}
I'm not sure what was causing the 0-length buffer, but it seems to be as a result of how/when the msg is sent in your test func.
So, I've been thinking about adding a means to make the Connect() method blocking as an option. Doing this would make your example work just fine. I'll bump this up on my priority list, and try to put some better "toggle blocking" options in this lib.
EDIT:
In an async context, normally you would put your commands to send a message separate from the commands that open the socket, because that's how async works. It depends on the msgs/signals sent. Technically the coder is supposed to wait for the
FD_WRITE signal (within the callback) before sending something.
FD_WRITE means "ok I'm ready to send a msg now". So your little error was just a result of sending the message early, and then for some reason an extra packet with 0 bytes to read was also sent, and my example wasn't setup to handle that.
So, yah, this lib needs to be "blocking friendly".