Sorry Tyranus, TESLACOIL and I appear to have hijacked your thread :-)
Have you made any progress in your MUD server?
FB, Winsock, and Networking
Re: FB, Winsock, and Networking
Not yet. Planning to try and tackle some more of it over the weekend. I'd say you can maybe expect another half a dozen questions tomorrow. :P
Re: FB, Winsock, and Networking
Had a chance to work on it some yesterday. Typical day in the life for a programmer there. Spent most of the day reading, referencing, and being frustrated. I wound up going back to D.J. Peters's example code that I tweaked from before and modifying that. After a bit more tweaking and some voodoo I'm still not quite sure about, I ended the day with a crude but working TCP/IP server that forks (via ThreadCreate) to handle multiple clients.
Guess I'll have to make one for UDP one of these days too, but that's enough of a win to make me happy for one night. :)
Guess I'll have to make one for UDP one of these days too, but that's enough of a win to make me happy for one night. :)
Re: FB, Winsock, and Networking
I've used UDP in some detail before (LAN only). You can do some interesting stuff with it, but it takes more work to get running than TCP because its not 100% reliable like TCP is. It's maybe 99% reliable, but you still have to handle the possibility of errors (message not received, multiple copies of the same message, out of order messages).
Have you been watching the other thread Teslacoil and I have running. We got a simple chat program working yesterday, from the UK to Australia. The program is messy and there are may things that may cause problems, but it works.
The link is: http://www.freebasic.net/forum/viewtopi ... =3&t=19690
Have you been watching the other thread Teslacoil and I have running. We got a simple chat program working yesterday, from the UK to Australia. The program is messy and there are may things that may cause problems, but it works.
The link is: http://www.freebasic.net/forum/viewtopi ... =3&t=19690
Re: FB, Winsock, and Networking
I read it a little while back but didn't follow too closely because UDP won't work for standard text-based MUDding. I am wondering, however, if it could be useful in the context of a graphical MUD. I think it would be neat (a pain in the butt, but neat) to code a MUD that is playable by either a text client or a graphical one. Trying it would almost certainly mean needing to build a client for it, but who knows?
Anyway, it seems to me that most games these days open TCP and UDP ports in order to run different chunks of their systems, so if I do any advanced multiplayer game design, I'll need to get a handle on both methods of socketmongering.
I'll have to take another look at that thread you referenced. And thanks again for those other links too.
Oh, yes. As promised, I do have questions. I'll need to poke around a bit more in the server code to figure out which ones are worth asking, but I've never worked with mutexes before. I'm getting the impression that they're a very necessary tool when multithreading, but I'm not sure how they behave. I don't want to halt the processing on every client just because a data collision *might* be imminent somewhere. Is that what a mutex will do?
If so, what's to stop me from designing a less draconian state machine that just signals whether or not the clients are clear to read and write to the data table and doesn't bother stopping them from operating normally otherwise?
Anyway, it seems to me that most games these days open TCP and UDP ports in order to run different chunks of their systems, so if I do any advanced multiplayer game design, I'll need to get a handle on both methods of socketmongering.
I'll have to take another look at that thread you referenced. And thanks again for those other links too.
Oh, yes. As promised, I do have questions. I'll need to poke around a bit more in the server code to figure out which ones are worth asking, but I've never worked with mutexes before. I'm getting the impression that they're a very necessary tool when multithreading, but I'm not sure how they behave. I don't want to halt the processing on every client just because a data collision *might* be imminent somewhere. Is that what a mutex will do?
If so, what's to stop me from designing a less draconian state machine that just signals whether or not the clients are clear to read and write to the data table and doesn't bother stopping them from operating normally otherwise?
Re: FB, Winsock, and Networking
Mutexes are generally required when multi-threading. You could setup your program so that it doesn't need them, but in most cases you'll have to use them for some things.
An example of where you might use a mutex is, say you have a network server with 1 thread listening for new clients, several threads which run the clients already created, and 1 thread for the user input and general interface. You would probably have a list of all the clients running. If a new client connects the listener thread would create a new client and add it to the client list. If the interface thread wanted to send a message to all the clients then it would access the client list and move through each client and add the message to it. Now, what if both of these events happened at exactly the same time. The listener thread would change the list while the interface thread was reading it, which could cause any number of errors, most of which are hard to trace back to their source. The solution is to enclose the list access commands within a MutexLock/MutexUnlock so that only one thread can access the list at once.
You can structure your program so that use use of mutexes and the time spent with a locked mutex is minimal, so then the performance drop from using mutexes is not noticeable. One thing to mention is that you only need to use a mutex if one or more of the threads needs to change the data. If all the thread will only ever read the data (and it will never change while the threads are alive) then you don't need to use a mutex, because the access is read only. If any thread might change the data then use a mutex.
In my experience, when multi-threading always assume that if it can go wrong, it will go wrong. If one thread can change data while another it reading it, even if the data is unguarded for the smallest amount of time, then assume it will at some point and an error will occur. The program may even crash entirely.
One final thing to mention. Say you have a number of threads running and they all check a single shared value to see if they should continue running or exit. You do not need to use a mutex in this case because you will only change the value once, and it doesn't matter what the value is, only if it is zero or not.
An example of where you might use a mutex is, say you have a network server with 1 thread listening for new clients, several threads which run the clients already created, and 1 thread for the user input and general interface. You would probably have a list of all the clients running. If a new client connects the listener thread would create a new client and add it to the client list. If the interface thread wanted to send a message to all the clients then it would access the client list and move through each client and add the message to it. Now, what if both of these events happened at exactly the same time. The listener thread would change the list while the interface thread was reading it, which could cause any number of errors, most of which are hard to trace back to their source. The solution is to enclose the list access commands within a MutexLock/MutexUnlock so that only one thread can access the list at once.
You can structure your program so that use use of mutexes and the time spent with a locked mutex is minimal, so then the performance drop from using mutexes is not noticeable. One thing to mention is that you only need to use a mutex if one or more of the threads needs to change the data. If all the thread will only ever read the data (and it will never change while the threads are alive) then you don't need to use a mutex, because the access is read only. If any thread might change the data then use a mutex.
In my experience, when multi-threading always assume that if it can go wrong, it will go wrong. If one thread can change data while another it reading it, even if the data is unguarded for the smallest amount of time, then assume it will at some point and an error will occur. The program may even crash entirely.
One final thing to mention. Say you have a number of threads running and they all check a single shared value to see if they should continue running or exit. You do not need to use a mutex in this case because you will only change the value once, and it doesn't matter what the value is, only if it is zero or not.
Code: Select all
Dim Shared As Integer continue_running = 1 ' Set to zero to stop threads
Sub some_thread(ByVal param As Any Ptr)
While continue_running ' Loop while continue_running <> 0
' Do stuff
Wend
End SubRe: FB, Winsock, and Networking
yes sorry for the hijack
pestery & i did get 2 way chat going and it seemed stable, that code could easily be used to create 1v1 head to head turn based game.
It was a no brainer for the client to connect..i didn't touch any hardware my end just ran the exe ( with correct ip) and we where in chat. Though pestery had to configure his ports etc so i could connect to him.
key point with ANY multiplayer games is you have to make it a no brainer for the client to connect, the first hint of hassle and players will bail...if your grandmother, post sherry glass lol cant figure out how to connect then you have nothing,nada, sweet FA
@ Tyranus
It doesn't matter if you use a tin can and a bit of string as a protocol, if it works then its a winner. That is the only rule you need to apply.
List of TCP and UDP port numbers
http://en.wikipedia.org/wiki/List_of_TC ... rt_numbers
TCP and UDP Ports Explained
http://www.bleepingcomputer.com/tutoria ... explained/
A multiplayer game is a universe of 0s and 1s.....agents (players) (server/gameai) can flip those bits. You cannot ever rely on players having a stable connection, thus the system, the universe must exist and be stable over time while it is effectively under attack from shedloads of clients connecting/dropping/and trying to read or flip all those bits. Imagine a 1000 client monkeys on 1000 typewriters...that pictures not too far from the truth, lol
Turnbased games have a tolerance measured in seconds.... and can be made fairly robust
Realtime games have almost zero tolerance to delays,errors,drops etc...something almost beyond the laws of physics to achieve
Data Integrity is key the game universe must remain coherent or it goes 'pffft'
http://en.wikipedia.org/wiki/RAID
Using high RAID number 'type strategies' for your game data is what its all about. Server or client crash is bad enough, but a data crash looks like this http://www.youtube.com/watch?v=dsx2vdn7gpY :-p
pestery & i did get 2 way chat going and it seemed stable, that code could easily be used to create 1v1 head to head turn based game.
It was a no brainer for the client to connect..i didn't touch any hardware my end just ran the exe ( with correct ip) and we where in chat. Though pestery had to configure his ports etc so i could connect to him.
key point with ANY multiplayer games is you have to make it a no brainer for the client to connect, the first hint of hassle and players will bail...if your grandmother, post sherry glass lol cant figure out how to connect then you have nothing,nada, sweet FA
@ Tyranus
It doesn't matter if you use a tin can and a bit of string as a protocol, if it works then its a winner. That is the only rule you need to apply.
List of TCP and UDP port numbers
http://en.wikipedia.org/wiki/List_of_TC ... rt_numbers
TCP and UDP Ports Explained
http://www.bleepingcomputer.com/tutoria ... explained/
A multiplayer game is a universe of 0s and 1s.....agents (players) (server/gameai) can flip those bits. You cannot ever rely on players having a stable connection, thus the system, the universe must exist and be stable over time while it is effectively under attack from shedloads of clients connecting/dropping/and trying to read or flip all those bits. Imagine a 1000 client monkeys on 1000 typewriters...that pictures not too far from the truth, lol
Turnbased games have a tolerance measured in seconds.... and can be made fairly robust
Realtime games have almost zero tolerance to delays,errors,drops etc...something almost beyond the laws of physics to achieve
Data Integrity is key the game universe must remain coherent or it goes 'pffft'
http://en.wikipedia.org/wiki/RAID
Using high RAID number 'type strategies' for your game data is what its all about. Server or client crash is bad enough, but a data crash looks like this http://www.youtube.com/watch?v=dsx2vdn7gpY :-p
Re: FB, Winsock, and Networking
"RAID" strategies won't help much if the power goes out on your server (or spontaneously reboots for some reason), and the memory is erased, containing BOTH copies of your RAID game state :-)TESLACOIL wrote:
Using high RAID number 'type strategies' for your game data is what its all about. Server or client crash is bad enough, but a data crash looks like this http://www.youtube.com/watch?v=dsx2vdn7gpY :-p
Re: FB, Winsock, and Networking
You dont have the game data in volatile memory you have it saved to disk
you use all kinds of data safe strategies , belt n braces +++
as with my AI system it doesn't run in memory as such EVERYTHING is saved to disk ASAP and with multiple copies
The more DATA you have in ram the bigger the nightmare to unravel. If You set the universes Clock Tick rate 10x slower than saving data to HDD then at most you will lose a couple of ticks. If its a turn based game then only a tiny % of the players data will be corrupted. You will only have to send them back in time a couple of universe clock ticks. If the tick rate is slow and the number of ticks lost is low then playing catchup is n x easier.
Crashes in real-time games are invariably fatal as a huge amount of game data is stored in ram. Thats why the maximum number of players in realtime games is so low. But turnbased servers can handle 1000s and can recover from minor crashes/data corruption on the fly.
As few people will have access to high end server hardware building extra layers of data protection into you creaky ole 'desktop' server is a smart move. You have to be really pedantic on the data front. If you have a lot of data you will also start to suffer from 'bit rot' If you dont have multiple levels of 'raid like protection' this is going to cause you a world of pain admin wise.
Cheating in online games , list of issues you typically have to deal with
http://en.wikipedia.org/wiki/Cheating_in_online_games
Blizzard Auctioning World of Warcraft Server Hardware
http://www.tomshardware.com/news/WoW-Wo ... 13712.html
just my 2cents from the perspective of many years as gamer and my first hand experience trying to build a 'never fail' AI system
you use all kinds of data safe strategies , belt n braces +++
as with my AI system it doesn't run in memory as such EVERYTHING is saved to disk ASAP and with multiple copies
The more DATA you have in ram the bigger the nightmare to unravel. If You set the universes Clock Tick rate 10x slower than saving data to HDD then at most you will lose a couple of ticks. If its a turn based game then only a tiny % of the players data will be corrupted. You will only have to send them back in time a couple of universe clock ticks. If the tick rate is slow and the number of ticks lost is low then playing catchup is n x easier.
Crashes in real-time games are invariably fatal as a huge amount of game data is stored in ram. Thats why the maximum number of players in realtime games is so low. But turnbased servers can handle 1000s and can recover from minor crashes/data corruption on the fly.
As few people will have access to high end server hardware building extra layers of data protection into you creaky ole 'desktop' server is a smart move. You have to be really pedantic on the data front. If you have a lot of data you will also start to suffer from 'bit rot' If you dont have multiple levels of 'raid like protection' this is going to cause you a world of pain admin wise.
Cheating in online games , list of issues you typically have to deal with
http://en.wikipedia.org/wiki/Cheating_in_online_games
Blizzard Auctioning World of Warcraft Server Hardware
http://www.tomshardware.com/news/WoW-Wo ... 13712.html
just my 2cents from the perspective of many years as gamer and my first hand experience trying to build a 'never fail' AI system