I'm making an program witch reads packets from server/client, first of all it reads size of the packet(it may be 1-5 bytes in size), and then reads what's left.
Problem: TCPRecv($socket,1,1) tooks really long to receive 1 byte, most of the time 100ms!
You can see packets here and how much time it took to read size of them(1-5 bytes, all of them are 1 byte in size): 0xAA63 (99.8802703210873ms) 0x53 (99.8829718030123ms) 0x2B (99.7435753356861ms) 0x4E (100.176352740059ms) I want to interrupt sometimes server or client, send packets, but I cannot send packets if server/client didn't get last packet. Sometimes packets are huge(16MB or even more), sometimes they are 2-6 bytes in size. I just don't want to receive everything and just send it. I want to see every packet, and collect data from these packets.
EDIT: I receive couple packets at the same time with TCPRecv to make it faster. I use TCPRecv($socket,10000,1). It made program a bit faster... But still, when receiving again these packets, it still tooks 100ms. It's still slow.
How to make TCPRecv($socket,1,1) faster? I don't need any error checking or etc., just to make it as fast as possible. (I only receive everything in hexadecimal)
I really need help with this... It's so slow and annoying!
I downloaded FF.au3 , installed MozRepl, started it, put 4242 as port in it, then when Im trying to run this simple script :
#include "FF.au3" _FFConnect(default,Default,6000) _FFWindowOpen("http://www.youtube.com", True, True) The thing is, it actually works, but it is still gives me a very annoying error :
What can do ?
Hello, I've done some testing and I've noticed that TCPRecv is slow, but it's almost exactly 1ms each time it's called if the socket is a valid socket and not a dead socket...So this got me thinking about the line in the help file about TCPRecv idling the CPU, presumably to allow people to call it continuously inside an extremely tight loop without running the CPU usage up too bad. I've been making a chat client/server (which I won't bother posting since it seems just about everyone has made those, it would just be another fish in the sea) and I always wondered why in my stress-testing, it would conk out after around 300-350 separate clients and then the interpreter itself would lock up and fail to respond.
I think I've found out why it does this after some investigation into TCPRecv, what happens when too much data is buffered without flushing it with another call to TCPRecv (interpreter locking up), and ultimately why said chat server is limited to a few hundred clients...after some more testing, that delay gets to be pretty high the more clients the server caters to. If the server has 50 people on it, it's doing around 50ms of sleeps each time it loops through to check the clients just from the calls to TCPRecv..so once it gets around 300-350 clients on at once, it's waiting 300-350ms total each time it does a loop. This ends up delaying all clients connected by basically 1ms per client connected plus their actual latency to the server, which is not that good...
I know some people may think "If you want to have a server cater to that many connections in a timely fashion, you should use a different language..." but I'm really only doing this for the experience, I have no intentions of actually letting this stuff roam free in the wild
Anywho, I figured I would test out trying to reinvent the wheel, to call the recv function in Ws2_32.dll and basically make my own version of TCPRecv that would work without the delay in it (assuming that 1ms time was an artificial delay put there by the AutoIt devs to idle the CPU) and see if that could do the job any faster...But that is when I started running in to the issue I am having right now, and where my lack of C/C++ knowledge is really starting to bite me in the behind.
Below is the function I tried making to emulate TCPRecv but failed at doing so...DllCall is setting @error to 1, which according to the help file says it was unable to access the dll, but I know from previous experience that AutoIt has no problem using Ws2_32.dll (the function _SocketToIP that has been floating around here for ages is one semi-well known one that calls this dll) so I'm guessing it's an issue with my lack of experience in the dark side of AutoIt so to speak...
Func _TCPRecv($iSock, $iLen) Local $structBuffer = DllStructCreate("char[" & $iLen & "]") Local $aRet = DllCall("Ws2_32.dll", "int", "recv", "int", $iSock, "char", DllStructGetPtr($structBuffer), "int", $iLen, "int", 0) If @error Then SetError(1, 0, "") Return SetError(0, $aRet, DllStructGetData($structBuffer, 1)) EndFunc
Any insight about TCPRecv's delay or my failed attempt at reinventing the wheel would be greatly apriciated!