ferbfletcher

Thank you!

"Right away" isn't really the best description. Even if I wait for some time, the send after the socket close still shows success. It's like it doesn't really close until it gets some input first. I'm having to rewrite some of my scripts to open and close the TCP connection at every TCPSend since it can't detect when this happens.

Ok, in your most recent example, in Sender.au3, change Sleep(2000) to Sleep(8000). Now, if you watch the tooltips, you will see test 1 no errors (the server shows the data), then server closes socket, then test 2 no errors! (but the server does not actually show the data), then test 3 error like you would expect. You can even go up to Sleep(12000) and then the server will close the socket, and the server will do tcpshutdown, and the client will still show no error on that 2nd test.

This might be a good example, at least to show the issue. The issue is that there is no failure detected on the first attempt after the socket closed. Look at this server. It accepts a connection, and then it immediately closes that socket, and goes into that nested while loop (just so it doesn't exit the program) so the client should fail on the 1st attempt of sending something. However, the client does not show any failure until the second sending attempt. TCPStartup() $socket = TCPListen("0.0.0.0",5000) While 1     Sleep(10)     $mysocket = TCPAccept($socket)     If $mysocket = -1 Then ContinueLoop     TCPCloseSocket($mysocket)     While 1         Sleep(10)     WEnd WEnd And this client: TCPStartup() $socket = TCPConnect("127.0.0.1", 5000) MsgBox(262144,1,"Connection Result=" & $socket) $result = TCPSend($socket, "Hello1" & @CRLF) MsgBox(262144, 1, "1.Result=" & $result & " Error=" & @error) ;This should fail, but it shows successful $result = TCPSend($socket, "Hello2" & @CRLF) MsgBox(262144, 2, "2.Result=" & $result & " Error=" & @error) ;This should fail, which it does $result = TCPSend($socket, "Hello3" & @CRLF) MsgBox(262144, 3, "3.Result=" & $result & " Error=" & @error) ;This should fail, which it does TCPShutdown()

Edit: Disregard this example, I see that it is going to create a million tcpaccept sockets. I'll try to come up with a better example. Try this test server with your client: The server will close the listen socket and close the accept socket after 15 seconds (but the server program does not exit), and your client still shows successful result after 15 seconds. Just make sure to do the first client send before 15 seconds and then wait for the server 15-second message to appear before continuing to the client's 2nd send. I am getting a successful message, no error, on all 3 sends this way, even after closing both sockets. TCPStartup() $socket = TCPListen("0.0.0.0",5000) $timer = TimerInit() While 1 $mysocket = TCPAccept($socket) Sleep(10) If TimerDiff($timer) > 15000 Then ;wait 15 seconds before closing the sockets so you can do 1 client test before this point TCPCloseSocket($socket) TCPCloseSocket($mysocket) msgbox(0,0,"sockets closed now") While 1 Sleep(10) ;loop just to keep the program running without doing anything WEnd EndIf WEnd

I just tried it like this described below to make sure it is reproducible, and trying not to make this too much about the server: In my example above, connect to google's ip address and port 80 in the tcpconnect. In my case it was TCPConnect("172.217.10.142","80") At the first msgbox, you should get a success message. Now, unplug your computer's network cable or disconnect your computer's wifi, however you are connected to the network. Close the msgbox so that it continues. Even with the network disconnected on your computer, it still shows successful on the next connection (and actually on both). Why does it think that it is successfully sending to a remote host (Google in this case) if the network is unplugged? I'm using Windows 10 1809

It seems that TCPSend cannot detect with the server has disconnected or closed the socket until it sends TWICE. For this example, you need to have a TCP server running on port 5000 or whatever. TCPStartup() $socket = TCPConnect("127.0.0.1", "5000") $result = TCPSend($socket,"Hello" & @CRLF) $error = @error MsgBox(0,0,"Result=" & $result & " Error=" & $error) ;The MsgBox shows a successful result and no error ;While the MsgBox is still open, close the server program, and then close the MsgBox to continue with the 2nd TCPSend run $result = TCPSend($socket,"Hello" & @CRLF) $error = @error MsgBox(0,0,"Result=" & $result & " Error=" & $error) ;Although the server is closed, the MsgBox shows a successful result and no error!  How is this possible??? And how can I detect this so that I can reconnect and resend if it shows successful? ;Close the MsgBox and let the 3rd TCPSend run now $result = TCPSend($socket,"Hello" & @CRLF) $error = @error MsgBox(0,0,"Result=" & $result & " Error=" & $error) ;This time, the MsgBox indicates a failed run and returns an error.

They are all Windows 10, 64-bit. I just tried it, just now, on someone else's computer to make sure again, it hung as well.

I'm not sending blanks in the loop. I'm sending a ton of x characters. You should see where $mydata is populated with x's at the top. My samples here are not using that linux server. I can duplicate this with autoit code, as shown above. I can duplicate this on every computer I try it on, using your scripts (your autoit client + your autoit server) or my scripts. All you have to do is either run both of my scripts, or run both of your own scripts after changing 8192 to 100. Again, slowing down the data will not help. A 5 second delay will not help. It will just make it take longer to hang. It doesn't matter if there is anything wrong with the server or not, tcpsend should return an error if it needs to. There probably is nothing wrong with the server. There are many things that can cause a server or connection to be slow or not respond for a while (congestion, busy doing other things, etc). It is not the job of the client to try to work around issues. So, even if you do work around this one specific issue, you could run into it again in the future under other circumstances. Just the fact that it is possible for it to happen makes it unacceptable. Talking to the developer of the server is definitely not a solution. There are millions of servers out on the Internet, and someone else is bound to run across this issue as well and either report it here, or not report it and just stop using autoit. So, fixing 1 server to workaround the tcpsend issue only pushes away the incentive to actually fix the real problem inside of tcpsend.

Thank you for your time here. For this particular project, I am stuck with that server. As a work-around, I am opening and closing the socket every time inside the loop instead of making a persistent connection, which works, but isn't ideal. I would like to be able to use persistent connections in the future without being concerned about this issue popping up, because while a program can deal with errors, it is impossible for a program to recover itself when hung. I have opened a trac ticket ... I'll see what happens with that.

I am currently using version 3.3.14.2 This does NOT happen in 3.3.8.1 Here is what happens in 3.3.8.1: After it reaches that hanging point, it hangs for a few seconds, and then it continues for awhile, and then it hangs for a few seconds, and then it continues for awhile. So, it seems that 3.3.8.1 is retrying after the server stops accepting data, and then it successfully continues sending when the server is ready again, while 3.3.14.2 simply hangs forever.

Your script hangs as well, at almost the exact place as my script, if you change the TCPRecv buffer in your server from 8192 to 100. Whether or not those are good numbers to use is not the point. The point #1 is that the server should never be able to cause the client to hang like that without any errors, and point #2: you cannot always modify or even see the server configuration, like in my case the server is a linux server that I have no control over. Also, your script, even at 8192, might still hang (but to prove it you might have to wait a super long time because of that larger buffer). So, it does seem like the server is causing an issue where it can't accept data past a certain point, but the client (TCPSend) should simply return an error so it can catch that issue instead of hanging forever... no different that if the server goes offline during the sending, the client simply throws an error. This issue should be no different. There has to be something within the built-in TCPSend function that isn't properly catching a race condition or something.

Even if I slow the client way down, like sleep(1000) instead of sleep(10), it still hangs at the exact same iteration every time .. so the speed isn't the issue. Also, even if I decrease the data size (like to 1/10 of the size), it still hangs after the same amount of data has been sent.. you just have to wait longer for it to send that amount of data .. so it isn't the amount of data being sent at a time that is the issue.

The actual server is not a script. It is a proprietary linux server of some sort that accepts TCP input, but the identical thing happens with it, the autoit client hangs after some time... so the simple server script above is included just so that the client example will run. I'm not actually sending that much data that quickly, that's just for the sample script to make the hang happen sooner so you don't have to run it a long time. Regardless of the speed or amount of data or overflowing anything, the fact remains that tcpsend should NEVER hang. Return an error... that's fine. Lose data... that can be worked around. Hang with NO errors... that's a bug in my opinion. So... I'm curious, what are your thoughts on it hanging forever and not returning any errors?

Ok, here is a working example that hangs every time: SERVER CODE (This is not the actual server code, it's just so that the client below will actually run) The server code is not an issue, and it does not hang. Start the server BEFORE starting the client. Run both of these programs on the same computer. TCPStartup() $iListenSocket = TCPListen("127.0.0.1", 500, 100) Do $iSocket = TCPAccept($iListenSocket) Until $iSocket <> -1 ;if different from -1 a client is connected. while 1 $sReceived = TCPRecv($iSocket,100) sleep(10) WEnd CLIENT CODE (This hangs every time, around iteration 328. You will see the loop iteration increase by the mouse cursor). Start this after starting the server. TCPStartup() $iSocket = TCPConnect("127.0.0.1", 500) $x = 0 Local $mydata ;This is to make a realistically large amount of data for testing purposes For $a = 1 to 100 $mydata &= "xxxxxxxxxxxxxxxxxxxx" Next While 1 $x += 1 TCPSend($iSocket, $mydata) If @error <> 0 Then MsgBox(0,"Error",@error) ToolTip($x) ;this is for a visual indication of program running Sleep(10) WEnd

That's almost 400 lines of code, without any hint of when/where it is "pausing". I suggest that you put several _FileWriteLog() lines (each with a different message) all throughout the program. Then, the next time it "pauses", look at your logfile and see what the last line was that ran was. Then, based on that, you can narrow down the issue.

I don't think that AutoIT has a method to "clear the tcp buffer", or perhaps it is built into the TCPSend function. Regardless, if that was an issue, I would expect @error to be returned from the TCPSend function. Instead, the TCPSend function is never finishing, it simply hangs and you have to forcefully close the program. In order for a function to hang forever (it was hung for 2 weeks before I noticed it) without returning an error, that seems like a bug within the function.

I am constantly monitoring file contents and sending tcp data based on that. So there is data being sent over the tcp socket all the time. Not a lot of data, but a slow continual flow.

If I do something like this, it works; While 1 ... do something to populate $mydata TCPConnect($sIPAddress, $iPort) TCPSend($iSocket, $mydata) TCPCloseSocket($iSocket) WEnd However, if I do something like this, it hangs after awhile with "program not responding" TCPConnect($sIPAddress, $iPort) While 1 ... do something to populate $mydata TCPSend($iSocket, $mydata) WEnd TCPCloseSocket($iSocket) The second method does not close the socket between every TCPSend, in order to keep the connection open/persistent. Unfortunately, it seems that after a certain amount has been sent, the TCPSend function hangs forever. No error returned, it just hangs without proceeding with the spinning cursor and the "not responding" windows message in the title. Is there a maximum limit for keeping the connection open? Is this a bug?

It is a large complex procedure, however the contents of the procedure does not matter. Whether it is complex, or a simple 2 line select as shown above, either way, there are 2 (or more) tables returned. Regardless, many developers use it, and in my case I have no control over changing the stored procedure. I just receive whatever the procedure sends me. UPDATE: So, I did finally find the solution, and it is extremely simple. Hopefully this will help someone else who runs across this in the future: https://msdn.microsoft.com/en-us/library/ms677539(v=vs.85).aspx The query handle returned by .Execute() contains the 1st table, like always, and do whatever you want with the data. THEN, do .NextRecordset(), and the query handle will contain the next table, then again, do whatever you want with the data. Basically, just add that one line, and it's done.

No, that is directly accessing the tables on the db, not using the stored procedure.

You are mistaken, this is a standard thing and is used in many applications: https://msdn.microsoft.com/en-us/library/ms131686.aspx It is neither against common sense, nor it is deviant.

No, I cannot bypass the stored procedure.

Hi, I am using SQL.au3 (Chris Lambert v3.2) to connect and query a stored procedure, and it works except that my stored procedure returns 2 tables but this script is only seeing 1 of the tables. How can I retrieve the 2nd table? When I run the query in mssql studio, it shows both tables, one right after the other. I'm doing a query like this: $query = "exec spMyStoredProcedure". The stored procedure returns 2 tables, but I only get 1 in AutoIt. The stored procedure is like this: SELECT * FROM [TableA]; SELECT * FROM [TableB]; So, I need to be able to do something like this: DataTable tableA = ds.Tables[0]; DataTable tableB = ds.Tables[1];

Interesting, I do not see any memory increase with your example. It looks like the only difference is that you processclose before stdioclose. Why should the order of those 2 things matter?