TCPRecv (v3.3.10.2)

[Andreik]

I am not sure in whici way but something has been modified in TCPRecv function because this function worked well but now it makes no sense for me.

Server

TCPStartup()

$Server = TCPListen(@IPAddress1,12100)

Do
    $Socket = TCPAccept($Server)
    Sleep(10)
Until $Socket <> -1


While True
    Sleep(10)
    $Recv = TCPRecv($Socket,2048)
    $Err = @error
    ConsoleWrite($Recv & @TAB & $Err & @CRLF)
Wend


TCPShutdown()

Client

TCPStartup()

$Socket = TCPConnect(@IPAddress1,12100)

Sleep(5000)

TCPSend($Socket,'Test')

Sleep(5000)

TCPCloseSocket($Socket)


TCPShutdown()

Following the messages from server's console it can be easily seen that TCPRecv makes no difference between a disconnected client and a connected client that don't send data. In both cases @error = -1 and when data is received @error = 0. Now how should I know when the client is disconnected?

Edited February 5, 2015 by Andreik

[Danp2]

I know this topic has come up previously. You will likely find several related topics if you search the forum.

FWIW, I know that the way it was resolved in FF.au3 was to change the code to look for an error code > 0.

[Andreik]

The code above prove that @error > 0 won't wont. If a client is disconnected @error will be set as -1.

[bogQ]

off topic question from my side maybe but

on recive 

Failure: "" and sets the @error flag to non-zero. @error: -1 Socket error
Windows API WSAGetError return value (see MSDN).

As far as i know -1 is still non-zero value so why are you testing it with > 0 ?

Edited February 5, 2015 by bogQ

[Andreik]

What it's funny about this thing is that even if some bug reports has been made before, devs are not yet convinced that there is a problem about what @error returns.

[bogQ]

well im not 2 if you ask me,

your expecting from func that is designed to check if there is something recived or not, to check if socket is still connected...

if you need to check if socket is alive send something to it if it doesnt respond after some predefined time delite that socket.

Edit: i'm not saying that i'm against that it should work like that, im just saying that i don't see that as an obstacle in codding server and client side.

Edited February 5, 2015 by bogQ

[Andreik]

well im not 2 if you ask me,

your expecting from func that is designed to check if there is something recived or not, to check if socket is still connected...

if you need to check if socket is alive send something to it if it doesnt respond after some predefined time delite that socket.

Edit: i'm not saying that i'm against that it should work like that, im just saying that i don't see that as an obstacle in codding server and client side.

 

Of course everytime can be found solutions, what I don't understand is why would you change something that worked well (until v3.3.10) in something that doesn't work at all. And in my oppinion there should be an error code if I expect data from a disconnected client.

[bogQ]

"why would you change" I don't know why, this topic was for that specific problem

I remember that they try to play around with @extended for some reason but i don't know the end result of it.

edit: ouh and the ticket concerning that topic

https://www.autoitscript.com/trac/autoit/ticket/2596

and its last 2 comments are really interesting

Have a nice read 

Edited February 5, 2015 by bogQ

[Andreik]

To set @extended in certain conditions would be an elegant way to solve this issue and I hope next release will fix this. The good thing is that at least beta version (v3.3.9.15) work well because returns @error=0 when the client is connected (no matter if data is received or not) and @error=-1 when the client is disconnected.