Hi,
You know when you are transferring large memory banks over a Blitz established TCP connection over the internet [Using WriteBytes() and ReadBytes()], what exactly happens??? Over a LAN it doesn't really matter because the transfer speeds are too fast to notice, but over an internet connection (e.g. broadband 1Mbps Download/256kbps Upload)... If both the computers had the same speed connection what would happen?
Prediction of chain of events when sending file
================================
*File is in a memory bank at a "server".
*File is sent using WriteBytes() to a pre-established TCP stream.
*File is being uploaded @ 256kbps to a memory buffer.
*"Client" begins to download file (ReadBytes()) @ 1Mbps and catches up to already uploaded data.
*Client download speed is reduced to 256kbps to keep in line with incoming stream.
*Once "client" has received last bit of data the program moves onto next command.
================================
End of Prediction
Or alternatively, does the client wait until all of the data is uploaded before it starts to download it... I'm confused - could someone please clear this up for me as I'm trying to do a progress bar for sending large files across a connection and looping through a file byte by byte takes wayyyyyy too long. ReadBytes()/WriteBytes() is fast enough but I can't find a way to find out how much data has been sent or received until the command has completed. (The program halts until the ReadBytes() or WriteBytes() command has completed).
Any ideas? - Thanks in advance
Seb
I guess the data is being stored in chunks directly to memory (the bank) when recieved, probaby packet by packet.
The tcp protocol discards packets when the transfer rate is too high, and therefore adjusts the speed, but this is handled at a lower level.
For the progressbar, Try something like this:
lastpos = 0
pbsize = filelen/256
pbinc# = 1/pbsize
for curpos = 256 to filelen step 256
WriteBytes bank,tcpstream,lastpos,curpos
updateprogbar progbar,pbinc#
lastpos = curpos
next Just send the filesize of the file over before you start actually sending the file. Then they receiver will know how far along the progress is.
Why TCP was ever included in the basic language structure i will never know. Due to TCP's nature and the fact that Blitz cannot multithread, a slow TCP connection to a Blitz server app will almost deffinately stall/slow it down. Its unavoidable so do yourself and anybody else reading this post a favour and use UDP. Its easier to use and you can emulate a mutithreaded server without the hicups. You will have to implement your own error checking but thats half the fun. I suppose TCP has its uses in Blitz but i cant imagine it being anything serious. Oh and i have managed to fully traverse a nat/router without having to open any ports whatsoever! Works on 98/me/2k/xp/xp64/vista and its really easy. I just read about nat and how it works, then it came to me on the toilet one night. UDP and Blitz combined can produce serious online networked apps!
Real men code in TCP !
TCP is good if one know how to code it.
TCP is verry diferent from UDP.
I recomend use static size of every TCP message.
that way tcp works as good as UDP in blitz.
Like only tcp command i use today for sending data is.
readavail(128) ;For a 128 byte packet.
writebyteS () command.
Common mistakes !
NeverUse:
WriteByte()
WriteLINE()
WriteINT()
(the command above is no good for fast gaming.)
not using readavail() = Will slow down main.
Yes UDP is simpler but not safe ! and packets may come out corrupt,disorted etc.
UDP is only good for transferring Data when it doesn't matter if it gets lost, because it will be updated within' the same second anyway ... something like Player position, etc.
And other than you think AndyUK TCP is the most important part of the Language if it comes to online gaming and internet connections. Because only with TCP you can handle ftp, email, websites, filetransfer, etc...
There is a very easy workaround for Blitz how to handle internet connections without losing gamespeed .. actually you do not see a flicker at all in your game even if you download a 10 MB file...
Using 2 Programs!
First a Gamelauncher (windowed mode, hidden, ending itsself if gameprogram gives order to end or ends automatic). This one manages all TCP and starts the Gameprogram one second after it has established itself.
Second the Game Program (windowed or fullscreen). This does the quick UDP if needed.
The heart of that system is, that both programs control each other via a local Network connection.
Example:
GameProgram gives the order to Launcher "LoadFile from Server". While Gamelauncher loads File to Drive or to its internal bank sending it portionwise to the gameprograms bank, the Gameprogram continues with whatever action. Until it gets the message from Launcher "FileLoading finished". Then it loads the file from drive or from its own bank where it was placed without beeing visualy noticed and so on... (I prefere the drive method instead of bank to bank transfer ... advantage: while developing and testing its the easier way)
Actually since I have started to work with that technique I rarely made standalone programs... there are other advantages, too... The launcher can end the main program and reload it again with other screenresolution... the Launcher can check if there are cheat programs running in the background... it can even start and stop windows processes (in case you know what you do) ... it can check if the main program has been minimized due to another windows process and maximize it immediately ... everything without slowing down the main gameprogram.
I am personaly using it to transfer scores and game protocols to the server, where it is checked for "non-cheating" and then the result lists are updated there...
And for downloading the next level or data of neighbor areas in online games while one level/area is played...
I programmed this system, because I hated the mouse lags and the stopping of everything on the screen (particles, objects, players) when I used one program, only...
There are some programmers advising the usage of very small packets ... no good advice ... with TCP you always get hickups in your program ... there is always a reason why a server reacts slow to your request...
TCP, if it is used while looped action is happening on screen, must run apart from the action game in another simulated thread (another program!)
RaGR, This is some great insite. Can you post some simple code for me to look at. It Sounds like you know what you are talking about, and I would love to learn form a blitz working example. Thank You