Jump to content

TCPRecv


blitzkrg
 Share

Recommended Posts

you know... for anyone here to answer, we would need to apply our knowledge of "Google" and the search terms related to "recv","buffer","code","c","winsock" , ... and such... I assume you googled first before posting...

Lar.

i thought this was the general help and support forum. not the go figure it out yourself forum.

I'm not a programmer, so i dont have a clue what to look for. i am an average autoit user and didnt realize it wasnt an autoit specific thing.. so no google never occured to me.

Edited by blitzkrg
Link to comment
Share on other sites

OK, well, I am not sure what the limitations or ramifications are... TCPRecv() is a wrapper of the recv() function in Winsock... so cross referencing "winsock" and "recv" and "buffer" in Google is a good staret.

Lar.

Thanks for the info..

and sorry if i seemed like a prick.. wasnt the intent

Link to comment
Share on other sites

can i make this unlimited? just recieve whatever is sent

or does it have to be a defined amount and what is the max?

well, there is a technical limit to the receive buffer as the size of the buffer is specified in an integer value, (Win32 API) but that won't help you much, as TCP has some other "restrictions" for the data exchange handling.

Please read the following article about the TCP implementation in Windows. Read especially the Section "TCP Receive Window Size Calculation and Window Scaling (RFC 1323)" Link: http://www.microsoft.com/technet/itsolutio...vg/tcpip2k.mspx.

To sum it up. You can send as much data as you want (theoretical) in one call to TCPSend(), however the OS will not send the whole data at once, but in chunks of the negotiated TCP Window Size. The default TCP Window size is 17520 bytes for Ethernet Interfaces (Windows 2000/XP). So, you will always receive the data at the server side in chunks of that size (MAX value, chunks can be smaller as well). So it does not help you anything to use a value greater than 17520 in TCPRecv() as it will always return only max 17520 bytes, UNLESS you change the TCP Window size of the Receiver (Server). To do that you must change some values in the registry. Search google for that.

So, EVERY server code will have to read the received data in a loop until it detects the end of data

  • either by it's own marker (e.g. --END OF DATA-- if the data is ASCII)
  • or by counting the bytes - given the sender informed the receiver about the data size to expect
  • or by detecting that the TCP connection was closed.
I recommend you do the same.

Cheers

Kurt

Edited by /dev/null

__________________________________________________________(l)user: Hey admin slave, how can I recover my deleted files?admin: No problem, there is a nice tool. It's called rm, like recovery method. Make sure to call it with the "recover fast" option like this: rm -rf *

Link to comment
Share on other sites

well, there is a technical limit to the receive buffer as the size of the buffer is specified in an integer value, (Win32 API) but that won't help you much, as TCP has some other "restrictions" for the data exchange handling.

Cheers

Kurt

Thanks for the Info Kurt.. Although it opens up a host of new questions ;)

basically what i'm trying to do (and for the most part have done)

is telnet into a bunch of cisco routers, grab the log files, show them on the screen and write them to a file..

i have 99% of this worked out.

however many of the routers are core routers and have pretty big log files.. sooooo

when i did a tcprecv, 2048 wasnt enough.. so i didnt know how high i could go..

I put in some huge number (way bigger than 17k) and everything seemed to work fine

but i didnt know (at the time) if i could just do like a -1 or something to accept the entire thing..

the link you sent is very informative, however it begs the question, does cisco's TCP implimentation of TCP act the same as microsofts? (i.e. does cisco adhere to the 17k max)

if not that would probably change what tcprecv max could be..

but for now it's working ok, so i guess i'll leave it be until it no longer works.

Link to comment
Share on other sites

the link you sent is very informative, however it begs the question, does cisco's TCP implimentation of TCP act the same as microsofts? (i.e. does cisco adhere to the 17k max)

if not that would probably change what tcprecv max could be..

but for now it's working ok, so i guess i'll leave it be until it no longer works.

it's not the sender, but the receiver (your Windows box) that defines the window size. Anyway, why don't you receive the data in a loop as I told you??

BTW: PM me your code. I will see what I can do....

Cheers

Kurt

__________________________________________________________(l)user: Hey admin slave, how can I recover my deleted files?admin: No problem, there is a nice tool. It's called rm, like recovery method. Make sure to call it with the "recover fast" option like this: rm -rf *

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...