Andreik

TCPRecv (v3.3.10.2)

9 posts in this topic

#1 ·  Posted (edited)

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 by Andreik

When the words fail... music speaks

Share this post


Link to post
Share on other sites



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.

Share this post


Link to post
Share on other sites

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


When the words fail... music speaks

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by bogQ

TCP server and client - Learning about TCP servers and clients connection
Au3 oIrrlicht - Irrlicht project
Au3impact - Another 3D DLL game engine for autoit. (3impact 3Drad related)



460px-Thief-4-temp-banner.jpg
There are those that believe that the perfect heist lies in the preparation.
Some say that it’s all in the timing, seizing the right opportunity. Others even say it’s the ability to leave no trace behind, be a ghost.

 

Share this post


Link to post
Share on other sites

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.


When the words fail... music speaks

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

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 by bogQ

TCP server and client - Learning about TCP servers and clients connection
Au3 oIrrlicht - Irrlicht project
Au3impact - Another 3D DLL game engine for autoit. (3impact 3Drad related)



460px-Thief-4-temp-banner.jpg
There are those that believe that the perfect heist lies in the preparation.
Some say that it’s all in the timing, seizing the right opportunity. Others even say it’s the ability to leave no trace behind, be a ghost.

 

Share this post


Link to post
Share on other sites

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.


When the words fail... music speaks

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

"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 by bogQ

TCP server and client - Learning about TCP servers and clients connection
Au3 oIrrlicht - Irrlicht project
Au3impact - Another 3D DLL game engine for autoit. (3impact 3Drad related)



460px-Thief-4-temp-banner.jpg
There are those that believe that the perfect heist lies in the preparation.
Some say that it’s all in the timing, seizing the right opportunity. Others even say it’s the ability to leave no trace behind, be a ghost.

 

Share this post


Link to post
Share on other sites

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.


When the words fail... music speaks

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now