FASt Server - Win32 Socket Library and Tutorial ....

[Mark Jones]

Cool. :)
Here's a TCP/IP registry key testbed app.

Code Select Expand


; Mark Jones/Helios Studios 2005
; build as "console assemble and link"
include masm32rt.inc    ; "runtime" libs
include advapi32.inc    ; registry functions
includelib advapi32.lib

.data
    szKey       DB  "SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\",0
    szValue     DB  "GlobalMaxTcpWindowSize",0

.data?
    buff        DD  ?
    buffsize    DD  ?
    hKey        DD  ?
    keyType     DD  ?

.code
start:
    print chr$("GlobalMaxTcpWindowSize: ")
   
    invoke RegOpenKeyEx,HKEY_LOCAL_MACHINE,addr szKey,0,KEY_QUERY_VALUE,addr hKey
    test eax,eax                ; does the key exist?
    jnz nokey
    mov buffsize,4
    invoke RegQueryValueEx,hKey,addr szValue,0,addr keyType,addr buff,addr buffsize
    test eax,eax                ; is there a GlobalMaxTcpWindowSize value?
    jz valfound
    print chr$("value not present.")
    jmp endit
nokey:
    print chr$("key not present!")
    jmp endit
valfound:
    print ustr$(buff)
endit:
    Invoke RegCloseKey,hKey     ; close key
    mov eax, input(13,10,13,10,"Press enter to exit:")
    invoke ExitProcess, 0       ; exit gracefully
end start


[James Ladd]

Mark,
Thanks for that snippet of code. Ill include it if its ok ? ie: When you startup FASt Server Ill dump the values.
Ill also look at the link you have posted. The only downside with proper optimisation of tcp ip is that the
best results are gained from knowing the clients settings, yet no hand-shake protocol seems to allow for this.

WebRing,
If you would like to write an ftp server then please do.
Proper use of FASt Server is the only way it will improve. Thanks for your offer.

All,
Thanks for your support. Im working full time, but every spare mo, ill put into FASt Server.
Im half-thinking a windows only bittorrent clone would be kewl ?

Rgs, striker

[Mark Jones]

Mark, thanks for that snippet of code. Ill include it if its ok?

Sure, it's just a testbed app, tinker with it. :)

The only downside with proper optimisation of tcp/ip is that the
best results are gained from knowing the clients settings, yet no handshake protocol seems to allow for this.

Well, when you're coding your own server, any data transmissions are possible. ;)

Only problem is, most of the TCP/IP parameters are initialized at boot-time; changing them per-session would have little effect. (FastSvr could however say "Yo, your TCP/IP parameters suck... update and reboot?" :bg

I'm half-thinking a windows only bit-torrent clone would be kewl?

Yikes, that would be a truly massive undertaking even for a team of coders. I thought you didn't have much free time? :green2

[roticv]

I think coding a bittorrent client is waste of effort. I rather support Homer and his p2p. Did you take a look at my comments?

[James Ladd]

Mark,
I mean that the servers best through put is when its buffer sizes are in tune with the clients.
There is no point in the server setting a buffer of 512 bytes when the client can only receive 256 at a time.
So ideally the client should tell the server what its sizing is.

Victor,
I was not suggesting a bittorrent client, but a windows server and client for doing very fast file
transferes.   Also, did you meant the comments here or on the other board/forum ?
I will be folding FAStUtil into FAStServer but I may pull it out again if demand is high enough.
Ill also make the plug-in an argument on the command line. :)

I dont have a great deal of time, that is true, but I also didnt say how long it would take.
:)

You guys are very talented and ideally Id like to leave plug-in support to you.

Rgs, striker.

[AeroASM]

You guys are very talented and ideally Id like to leave plug-in support to you.

Rgs, striker.

Yes, because then we get at least some of the credit!

[Mark Jones]

Mark, I mean that the servers best throughput is when its buffer sizes are in tune with the clients.
There is no point in the server setting a buffer of 512 bytes when the client can only receive 256 at a time.
So ideally the client should tell the server what its sizing is.

Curious, will the server be able to create multiple threads, each with different window sizes?

Okay, sounds simple enough. If I understand correctly, "window size" for the client is RWIN, "Receive Buffer Window Size", or at XP likes to call it, GlobalMaxTcpWindowSize. If we coded our own client it would be simple to poll the registry and send that value during handshaking. But how to determine a client's RWIN when they use IE or FTP? It shouldn't be too hard actually, simply echo ICMP packets while increasing their size. Once a packet is "fragmented", back off the RWIN value a notch and that should be the max.

Later: Oh, and maybe save the client's IP address in a lookup table on the server. That way, if they reconnect, the server pulls up their RWIN without having to calculate it.

[James Ladd]

Mark,
Were kind of on the same track.
The server will not know the clients RWIN without the client sending it to the server. So existing
protocols and tools like IE just wont do this. At least not yet.
I was just pointing out that the best throughput can be gained be knowing the clients settings.

AeroASM, Do you feel that there is some credit that you have not been given ?

Ill be doing a lot more on FAStServer tonight !
Watch for a new posting/version.

Rgs, Striker

[AeroASM]

No, its just that if you code plugins as well, then:

1. The actual FAStServer will be worse, because you have less time to spend on it
2. If you do not code the plugin, then I can, so I get the credit, instead of you! (not to be taken seriously)

[James Ladd]

AeroASM,
If there is anything I can do to assist the plugin you are/may develop then please let me know.
Rgs, striker.

[James Ladd]

All.

I did some significant development last night.
However, I didnt finish my experiment with various socket and WSARecv/Send buffer sizes
so I have not yet posted the update. It wont be long before I do.

Rgs, striker

[James Ladd]

All,
There is a new version of FASt on the site.
Still doesnt have proper plugin support but it will very very soon.

When I send a large chunk of data in one go, the server faults and I have to look into this.
Im blindly assuming the data read is the same size of the buffer so this is probably the issue.
Ill have another look later.

Comments are welcomed as are downloads :)

Rgs, striker.

[Mark Jones]

Are you sure you uploaded the new version? :)

[roticv]

I think you should give it verison a different file name, so we know we are getting a more updated file. Sometimes I have no idea whether it is the new verison or not, or I am just opening the version found in cache.  :'(

[Mark Jones]

I can always tell when James has posted a new version, because his page www.jamesladdcode.com shows the link as light blue, versus purple (visited.) Perhaps it's the same with IE and the other browsers?

Edited: misspelled Ladd, sorry James! :)