TCP-ing from client(s) to a server

Blitz3D Forums/Blitz3D Programming/TCP-ing from client(s) to a server

Blitzplotter(Posted 2008) [#1]
There is a couple of posts regarding transferring data and the like.

Tried to keep code minimalist so can be expanded further....

Using the client and server code below,compile them and
create a sub directory in the same directory as your compiled server_v2 and client_v2 executables, called file_dir.

This sub directory is used by the server to maintain a list of the clients that are running, without it the VB.net front end will not work.

I have developed a VB.net front end for the two executables server_v2 and client_v2 that keeps a running count of the clients running,
will kill the server and subsequently clean up the file_dir sub directory of historic client files. You do not want
to put any of your own files within the file_dir directory, this directory gets cleaned very well upon Kill Server!

Link to VB.net front end:
http://myweb.tiscali.co.uk/diecastcars/File_Counter.exe

NOTE: Do Not try to run the File_Counter.exe file before you have created a subdirectory call file_dir at the same path. Nothing BAAaaad will happen, it just wont work (;-)
So: You might want once you compile the two slices of code below, called them server_v2.exe and client_v2.exe respectively then put them at the same path as File_Counter.exe, else the start server and client buttons won't find what they need.


Server:



Client:




Hope this helps someone.....


Blitzplotter(Posted 2008) [#2]
Updated the Server and client code, the client code now sends move requests to the server. The server holds the master copy of where the clients are (x and y co-ords). The server sends out positional data of all clients to all clients.

new code does this:




The new client code sends out move requests to the server after a few iterations. If you start different clients a few seconds apart you will see the move requests being recieved by the server, the server updates the x and y co-ords of the client.... the rest is history.


You might want to drop the delay (set at 1200 = 1.2 secs).....

Server:






Wings(Posted 2008) [#3]
One way to cope with even more clients.. is to have a server que. that way server will only send some packets at a certain time. and it will kep the ISP happy :D

i have done this in my little rpg game.
so important packet arrive first. and broadcast then there is send time. a little like old fasion TimeSpace.


Blitzplotter(Posted 2008) [#4]
Hmm a server queue, might invest this more once ratify my 3d JV-ODE blah end zone truckin headache. Am using a vastly modified version of your ultrafast server Wings. thanks again, see here:
http://www.blitzbasic.com/Community/posts.php?topic=72220#864502


Wings(Posted 2008) [#5]
basic i store tcpip packet in a type and data in memmory bank.

i se that there is even flow on tcp sending..


this way one have controll over how much data that can be sent over stream. it takes planning..


Blitzplotter(Posted 2008) [#6]
Moved my game forwards a little, the code is nowhere near ready for public consumption, maybe it never will be - two trucks alive in my 3D arena which are clients to a server provided in the first instance by WINGS, modified a bit to take it to this. Wings has provided me with some more good advice that I've still to implement but all in good time.

I plan to have a new front end that will attempt to source the IP address of the client prior to executing the B3D code, maybe some logic to source the IP address of the server..... soon.