nullschritt Posted July 29, 2013 Share Posted July 29, 2013 (edited) There appears to be a limit to the number of bytes that tcpsend can send over any non-local connection. It appears if the data is too large it either doesnt send or gets cut short. It appears that in order to stream images over a network I would need to break the data up into packets, but does anyone know what the max packet size is over tcpsend? Edited July 29, 2013 by nullschritt Link to comment Share on other sites More sharing options...
nullschritt Posted July 29, 2013 Author Share Posted July 29, 2013 It might help to know I am using the P2P UDF by Hyperzap, which is based on the Event Driven TCP UDF. Link to comment Share on other sites More sharing options...
nullschritt Posted July 30, 2013 Author Share Posted July 30, 2013 Not that I need help specific to these examples, I'm sure I could adapt any example to work within the udf, so does anyone have any examples of how to send data as packets? Link to comment Share on other sites More sharing options...
Solution Gianni Posted July 30, 2013 Solution Share Posted July 30, 2013 (edited) HI nullschrittI think that to use TcpSend you do not have to worry about the size of the data you need to send, TcpSend sends what you pass to it and it will automatically break into packets.It is different when you receive with TcpRecv, you say how many bytes you want to try to receive, and if should be received more data than you have stated, you have to try to read more data until you get an empty string. I did some experiment getting some acceptable results, if you want to try here's >my (poor) test EDIT also this can be instructive: If you want send images over network, >here is a nice example by mr. Yashied: every time you run the client, it make a scrrenshot and send the image to the server. in short: when you run client and server on different computers, change the line $Socket = TCPConnect(@IPAddress1, 33891) in the client with the ip address of the server (so the client knows where to send the picture) compile both scripts, first run the server on the receiving computer and second run the client on another computer of your lan. bye Edited July 30, 2013 by Pincopanco Chimp small minds discuss people average minds discuss events great minds discuss ideas.... and use AutoIt.... Link to comment Share on other sites More sharing options...
nullschritt Posted July 31, 2013 Author Share Posted July 31, 2013 (edited) HI nullschrittI think that to use TcpSend you do not have to worry about the size of the data you need to send, TcpSend sends what you pass to it and it will automatically break into packets.It is different when you receive with TcpRecv, you say how many bytes you want to try to receive, and if should be received more data than you have stated, you have to try to read more data until you get an empty string.I did some experiment getting some acceptable results, if you want to try here's >my (poor) test EDITalso this can be instructive:If you want send images over network, >here is a nice example by mr. Yashied:every time you run the client, it make a scrrenshot and send the image to the server.in short: when you run client and server on different computers, change the line $Socket = TCPConnect(@IPAddress1, 33891) in the client with the ip address of the server (so the client knows where to send the picture)compile both scripts, first run the server on the receiving computer and second run the client on another computer of your lan. byeI implemented your method of waiting for a nullstring to be returned inside the p2p udf, as all data is sent with a header and footer, I can detect if the data has been truncated and sent in packet form.$rawrecv = TCPRecv($SocketID, 1024) $regex = StringRegExp($rawrecv, "--SIM:([0-9](.*?)[PRODY]){5}", 2) if IsArray($regex) Then recvprocess( $rawrecv, $SocketID, $Array_Slot, $iError) Else Do $recvtmp = TCPRecv($SocketID, 1024) $rawrecv &= $recvtmp until $recvtmp = "" recvprocess( $rawrecv, $SocketID, $Array_Slot, $iError) EndIf Not 100% sure how reliable this is, going to test it with some images later tonight. Edited July 31, 2013 by nullschritt Link to comment Share on other sites More sharing options...
nullschritt Posted July 31, 2013 Author Share Posted July 31, 2013 (edited) Okay after testing with images it appears that some lag inbetween sending data can cause the code to terminate reading the data early, when using this method, I will check out the second example linked to, and also try adding a small sleep to correct the problem and report back/.Edit: It seems that adding a simple sleep(10) into the loop prevents accidental pre-termination of the string, once again, thanks for the great pointer! Decided to try using detection of the footer rather than a sleep, resulting code is much faster. Edited July 31, 2013 by nullschritt Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now