TCPRecv and v3.3.12.0

[JScript]

Hello to all!

I will comment on the version v3.3.12.0, which I was surprised by the speed of the build really is super fast compared to previous!
The organization of includes folder is perfect, well synchronized and divided, congratulations to all who participate in the development of this wonderful scripting language.

However, I still used the version 3.3.8.1 because it still caters to the requirements of my code, but with the improvements in the current version, so I decided to install.

However, I have noticed that the TCPRecv () function does not work the same way in version 3.3.8.1, I've seen comments about it and I have seen that the behavior is really different!

Before I just used something like this code below:

$vDataRecv = TCPRecv($iConnected, 200)
If @error Then
    MsgBox(262160, "Error!", "A conexão com o computador remoto falhou!")
    Return 0
EndIf

However, with the new version does not work anymore, always returns me error! Could someone tell me another way to code up?

I appreciate everyone's help,

JS

[ripdad]

If you don't need anything special, perhaps this will work...

$vDataRecv = TCPRecv($iConnected, 200)
If Not StringRegExp(@error, '(-1|0)') Then
    MsgBox(262160, "Error!", "A conexão com o computador remoto falhou!")
    Return 0
EndIf

[JScript]

Hi

Hello, thanks for the reply, but unfortunately it did not work...

I'm testing as follows: If @error > 0 Then

JS

[ripdad]

what about @error less than -1 ?

http://www.autoitscript.com/autoit3/devs/jpm/%232384_UDPTCP_@error/UDPTCP%20@error.txt

UDPRecv

@error: -2 invalid socket.

-3 not connected.

-4 or -5 invalid socketarray.

UDPCloseSocket

@error: -4 or -5 invalid socketarray.

UDPSend

@error: -4 or -5 invalid socketarray.

1 - IPAddr is incorrect.

2 - port is incorrect.

TCPRecv

@error: -1 no byte received.

-2 invalid socket.

-3 not connected.

TCPConnect

@error: -3 not connected.

1 IPAddr is incorrect.

2 port is incorrect.

10060 Connection timed out.

TCPAccept

@error: -3 not connected.

Also the helpfile says that -1 is a socket error --

which it is Not, as you can see:

-1 no byte received.

[JScript]

This is quite interesting because it is not in the help file, but I only got success in this way:

If @error > 0 Then

JS

[ripdad]

The help file concerning TCPRecv needs to be corrected - as well as the TCPRecv examples.

As it stands, the examples will fail with @error -1.

Did you read this?

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

In my opinion, TCPRecv should be reverted. It worked just fine as it was.

Take care...

[jpm]

Please try the uploaded .exe as if we revert  #2384 will be in error again.

Thanks

[ripdad]

jpm,

That .exe is v3.3.11.5 beta. Are you saying to use this .exe - and for how long?

I'm just trying to understand the logic here. Most people would like to upgrade

when a stable version is out. At this point, I think people that use the TCP

functions heavily, are staying with v3.3.8.1 or earlier because of this issue.

Does the error codes in UDPTCP@error.txt apply to both the v3.3.11.5 beta .exe And v3.3.12.0 ?

Also, what was wrong with TCPRecv in v3.3.8.1 ?

Thanks for your time!

-Edit-

#2384 applies to this post:

'?do=embed' frameborder='0' data-embedContent>>

As far as I can tell, this is where this issue started - with UDPRecv.

Why does this fix affect TCPRecv?

If this function remains the same as it stands, then correction's need

to be made in the help file - otherwise this will be a reoccurring issue.

Thanks again!

Edited June 10, 2014 by ripdad

[jpm]

yes I want you validate this .exe as it is the solution I propose to Jon.

For the TCP/UDP recv the internal code is the same so that the reason of the change.

remember my proposal is to have unique @error on each different case so the -1 is change.

Thanks for the help

jpm

[ripdad]

jpm,

Okay, I'll run some tests over the next couple of days and get back to you.

[ripdad]

Hi jpm,

TCPRecv

@error: -1 no byte received.

-2 invalid socket.

-3 not connected.

This entire issue is about the "-1 no byte received" error.

There is nothing wrong when TCPRecv receives no bytes.

(1) If no bytes have been received, it is usually because the remote server has not

responded yet. This is not an error. The client is simply waiting on the server,

which usually responds within a few seconds.

(2) There are times during data transfer (for instance a file download of 1GB),

that a server or somewhere in between, pauses for a moment and then resumes a

few seconds later. This is not an error either.

In a loop, while waiting for data during those few seconds at 10ms sleep, could

result in hundreds of TCPRecv calls with no incoming data.

In the course of downloading a 1GB file, it is Normal to have as many as 200 instances

(or more) of "no byte received". This is not an error -- it's just the way things work

on the internet.

(3) In most cases, the First call of TCPRecv will be a blank string or no bytes received.

So a script will fail with -1, when this happens. Even though, nothing is wrong.

(4) In past versions, an error, any error, would normally cause a script to abort

a TCPRecv operation. As it stands now, it would take two different error checks --

one to check for "-1 no byte received" and another for socket errors.

Triggering an error because "no bytes have been received" is not needed. This is usually

taken care of by the scripter when they check for valid incoming data. On the other hand,

true socket errors like a closed connection, invalid socket or WSA errors, are very much

needed.

---

I understand that UDPRecv needed to be fixed.

Surely, there must be a way to make TCPRecv behave the way it did in past versions

(ie: v3.3.8.1), concerning no bytes received.

As it stands now, most TCPRecv scripts on the forum are broken as of v3.3.10.0.

That's including the examples in the help file.

Coded the way they are, there is no way they could work properly.

(ie: If @error Then Return False)

They will fail with -1.

If the function remains the same, I will treat the -1 as no error in my scripts.

---

The .exe worked fine (under the conditions you set up for it). No crashes or abnormal problems.

I only used the TCP functions - and transferred over 1GB of data while testing.

Thanks for your time.

[Iczer]

please consider move "no byte received" from @error = -1 to @extended = -1

i think it would be better, than drop this functionality

Edited June 11, 2014 by Iczer

[ripdad]

please consider move "no byte received" from @error = -1 to @extended = -1

i think it would be better, than drop this functionality

I have no objections with that.

[jpm]

Many Thanks

I will update the @error -1 no received data to @extended = -1

Cheers

[jpm]

Final test !!!

I reuploaded with the proposed changes

Cheers

[SlowCoder74]

I've been building a TCP server/client UDP and was balked by this very issue.

Thanks to ripdad for pointing me to this thread.  I concur with his statements about the illogical use of @error to indicate no data received.

So that I can document in my code, and so that I am sure of the issue, we are effectively reverting the @error codes to 0 (like in older versions of AutoIt) if no data received, but setting @extended to -1 in the next stable release of AutoIt?  What will the stable version number be?

[ripdad]

Thanks jpm, it's looking good -- Tested on about a dozen websites with no problems.

For those that wish to test the updated .exe, you can find it here along with the

updated error codes:

http://www.autoitscript.com/autoit3/devs/jpm/%232384_UDPTCP_@error/

[JScript]

Final test !!!

I reuploaded with the proposed changes

Cheers

 

Finally an elegant solution!

Thank you friend

JS

[ripdad]

jpm,

TCPRecv

@error: -1 invalid socket.

-2 not connected.

@extended: 1 no byte received.

I did some more testing and it still has a problem.

It won't detect disconnects, which -2 should cover that.

I'll be back within a couple of hours, with a small server-client reproducer.

-EDIT-

Okay, this is a quick script to show the difference between v3.3.8.1 and

the updated .exe, concerning a server disconnect to a client.

expandcollapse popup

If Not TCPStartup() Then
    Exit MsgBox(8208, '', 'Error: TCPStartup' & @TAB, 5)
EndIf
;
Local Const $strIP = @IPAddress1
Local Const $nPort = 8091
;
Local Const $Connection = TCPListen($strIP, $nPort)
If @error Then
    _TCP_Client()
Else
    _TCP_Server()
EndIf
;
TCPShutdown()
Exit
;
Func _TCP_Client()
    Local $nSocket = TCPConnect($strIP, $nPort)
    If @error Or ($nSocket < 1) Then Return

    TCPSend($nSocket, 'SEND_DATA_MARY')
    If @error Then
        TCPCloseSocket($nSocket)
        Return
    EndIf

    Local $string = ''

    Do
        Sleep(10)
        $string &= TCPRecv($nSocket, 32, 0)
    Until @error

    TCPCloseSocket($nSocket)

    MsgBox(0, '[Client] - Response From Server', $string)
EndFunc
;
Func _TCP_Server()
    Local $nSocket, $string = ''

    MsgBox(8256, 'Status', 'Server Online' & @TAB, 2)

    Do
        Sleep(100)
        $nSocket = TCPAccept($Connection)
    Until $nSocket > -1

    Do
        Sleep(10)
        If $string Then ExitLoop
        $string &= TCPRecv($nSocket, 32, 0)
    Until @error

    Switch $string
        Case 'SEND_DATA_MARY'
            Local $str = 'Mary had a little lamb, whose fleece was white as snow;' & @CRLF
            $str &= 'and everywhere that Mary went, the lamb was sure to go.' & @CRLF
            TCPSend($nSocket, $str)
        Case Else
    EndSwitch

    Sleep(250)
    TCPCloseSocket($nSocket)
    MsgBox(8256, '[Server] - Command From Client', $string)
EndFunc

How it works:

This script is a server or a client, depending upon which is run first.

Drop it on an .exe version of Autoit to run the server.

A msgbox should show that the server is online.

Then drop it again on that same .exe version to run the client.

Upon doing this, there should be two msgbox's -- one from

the server and one from the client at the same time. This

would be done if the client detects the server disconnect.

If only one shows up and it's the server, then the client

did not detect the disconnect.

Let me know if any questions.

Edited June 13, 2014 by ripdad

[bogQ]

ripdad your not checking client (informing yourself) for errors correctly on

    TCPSend($nSocket, 'SEND_DATA_MARY')     If @error Then         TCPCloseSocket($nSocket)         Return     EndIf

What if its tcpsend error and your not informed, your script just exits and dont display msgbox?

you dont even get to part did you even recive msg... you just asume you recive something in infinite loop on client untill some error?

another thing isnt -2 for if you forgot to connect to server before using command and not if server dcced you?

Edited June 13, 2014 by bogQ