Opened 7 years ago
Last modified 9 months ago
#3575 assigned Bug
TCP functions slow and TCPCloseSocket with shutdown
Reported by: | ripdad | Owned by: | Jon |
---|---|---|---|
Milestone: | Component: | AutoIt | |
Version: | 3.3.14.2 | Severity: | None |
Keywords: | Cc: |
Description
Here is a list of problems that I found with TCP in AutoIt, using v3.3.10 through v3.3.15, while transferring a 10mb string with TCPSend to TCPRecv. Please keep in mind, these are my observations using computers available to me and I have yet to test it on Windows 10. But be patient, it will come around eventually.
- TCPRecv will not detect a TCPSend -> TCPCloseSocket. It will detect a TCPShutdown. But, not if TCPCloseSocket is used first.
- TCPAccept speed is about 108ms, while v3.3.8.1 is about 15ms.
- TCPSend speed is about 200 to 650ms, while v3.3.8.1 is about 28 to 90ms. The higher the string is in size, the more exponential the time becomes. This leads to an unresponsive GUI.
Note:
I don't believe TCPSend is the problem, because I can use v3.3.8.1 to send and v3.3.14 to receive and it still has the same results. Yet, TCPRecv speed is about ~1ms. So, I don't know what's going on here.
- When TCPSend is paused, TCPRecv speed is about 108ms, while v3.3.8.1 is about 15ms.
Note:
This test simulates a delay on a server, which can be up to 10 seconds or more.
- Completion time of the 10mb string is about 28 to 64 seconds and v3.3.8.1 is about 7 to 10 seconds, depending on what computer is used for the test.
In conclusion, the TCP functions do indeed work, with the exception of #1. This is about timing issues within the code. The major issue is #3 - but all these problems combined just makes it worse.
It does seem to me, that a 100ms timer is in place with each of these functions, or possibly something that is common to all of them. If this is true, then it should not be any more than 10ms or none at all. I don't know if fixing that would solve it all, but it's worth a shot in my opinion.
You should have a way to benchmark TCP response times, to verify my statements.
The other TCP functions seem to be working fine. (ie: TCPConnect, TCPListen, etc.)
Attachments (0)
Change History (9)
comment:1 Changed 7 years ago by ripdad
comment:2 Changed 7 years ago by ripdad
In reality, that should act as a Timeout timer and not a Sleep timer.
So, it's still a bug in my opinion.
In the meantime, Opt('TCPTimeout', 10) is a workaround for it.
comment:3 follow-up: ↓ 4 Changed 7 years ago by Jpm
Sorry to ask so late, can i have repro scripts so I can analyse and try to find a solution
THanks
comment:4 in reply to: ↑ 3 Changed 6 years ago by Jos
Replying to Jpm:
Sorry to ask so late, can i have repro scripts so I can analyse and try to find a solution
THanks
JP, It looks like we need to do a shudown() before the closesocket() in F_TCPCloseSocket() to stop traffic from being accepted. Read this post and the next 4 posts: https://www.autoitscript.com/forum/topic/196642-tcpsend-bug/?do=findComment&comment=1410377
Jos
comment:5 Changed 4 years ago by Jpm
- Resolution set to Works For Me
- Status changed from new to closed
comment:6 Changed 4 years ago by Jpm
- Resolution Works For Me deleted
- Status changed from closed to reopened
comment:7 Changed 4 years ago by Jpm
- Owner set to Jpm
- Status changed from reopened to assigned
Re thinking of the pb I think it can be useful to add a TCPShutdownSocket(listensocket,1)
which can be called before TCPCloseSocket(listensocket)
this can be combined with an extension of TCPCloseSocket(listensocket, 1)
Addition sent to Jon
My last addition are to help the Jos finding. Nothing to do with TCP Slowdown
I could have open another ticket
comment:8 Changed 4 years ago by Jpm
- Summary changed from TCP functions slow to TCP functions slow and TCPCloseSocket with shutdown
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
I found the solution to the slow problem and was right about the 100ms timer.
Starting with v3.3.10.0, you must use Opt('TCPTimeout', 10) in your script
to behave like v3.3.8.1.
The #1 problem still remains.