ok i had looked at previous posts on Winsock and Multithreading and im wondering if anyone will kindly restart this thread on explaining how i would go about making a MUD text game
the server for this game will need to use winsock allowing TONS of connections and sending commands at the same time... what i got set up right now is that if one person sends a command at the same time as another it shuts off the one connection and goes to the newest one until a command is resent by the one that got shut off, so that's when i looked at the other post winsock and mulithreading and it confused the hell outa me so can anyone please help me out with this i'd REALLY appreciate it,
what confused me the most was all the terms and questions that i dont understand, so i can't follow along
Don't close connections unless the client wants to disconnect. It's better to provide uninterrupted service to some number of clients than randomly disconnect clients in order to process extra ones.
It all depends on the numbers of clients. TBH, if you're talking about a LOT of clients (i.e. several hundred), I'd really recommend looking into not using VB; for high-client situations you probably want to be using I/O completion ports and overlapped I/O, which isn't very feasible with VB.
I'm not sure what you want to know about multithreading with winsock, could you explain?
i had already went there and previous to me wanting to do this i had read wokawidgets thread on threading in general and im confused by it all, and yes im looking to have hundreds of people connectiong to this server.
From a quick glance, it all looks a bit inefficient for a game. Looks like huge amounts of overhead really. High-client count and/or high-throughput servers aren't VB's strongpoint to be honest; when the language works against you, you're better off using a different language.
but i dont know any other language and this si something i want done now, im kinda an impatient kinda guy lol, can anyone else varify what was previously said? becausei have high hopes for making this game
I've created a server once, also for a MUD like game. It was fully text based and the client was Flash. However, I've also created my own 'test' client because the Flash Client was created by someone other than me, so I needed something to test with.
What I experienced was that winsock tends to 'forget' information send to it by another (VB) client using Winsock. When two users where on at the same time, some data just got 'lost'. This problem was not noticed with any of the Flash clients. Later I found something on this board telling me that this was a Winsock bug, but it's still there unfortunately.
The advantage of using Flash is that it's online and you can make it more graphical
Here you can find a Class version of Winsock: http://www.vbforums.com/showthread.p...=Winsock+class
I didn't use this before, so I don't know if it works OK, but you could try anyway Maybe this will solve the 'forgetting' problem. You can even create an ActiveX EXE for multithreading and place the Winsock Class in there...
Good luck
"Experience is something you don't get until just after you need it."
FYI, multithreading is not the cure-all solution to creating high performance networked apps. Worry about the I/O model you want to use, then think how you need to implement it.
Of course if you use VB, the I/O model choice is rather limited (blocking, non-blocking, non-blocking with windows message notification) and the best techniques aren't feasible to implement in VB.
Disclaimer in case VB purists want to flame ( ): VB will work just fine for a low-client count server.
FYI, multithreading is not the cure-all solution to creating high performance networked apps. Worry about the I/O model you want to use, then think how you need to implement it.
Of course if you use VB, the I/O model choice is rather limited (blocking, non-blocking, non-blocking with windows message notification) and the best techniques aren't feasible to implement in VB.
Disclaimer in case VB purists want to flame ( ): VB will work just fine for a low-client count server.
Can you elaborate as to why the best techniques aren't feasible in VB? Also, I've seen the following terms in my searches:
I'm actually in the process of doing the same thing you are. In my case, I'm translating CircleMud to VB for some coding practice. I think you'll be fine using VB for your codebase as long as you do as much through the APIs as you possibly can. This means:
Step One. Read about Berkeley sockets and the Winsock API.
Step Two. Resist the urge to use a Winsock control.
Step Three. Read about Berkeley sockets and the Winsock API again.
Step Four. Try to implement your socket routines.
Step Five. Read about Berkeley sockets and the Winsock API again.
Setp Six. Repeat step four.
Then you should be able to get it off the ground. Personally, I'm at step four . Couple of things to keep in mind. First, you probably don't want to make your server event driven because this would prevent you from keeping all of your connections acting in the same timespace. Second, you probably don't want to multi-thread anything except for your administration functions, for the same reason. I'm doing mine as a activeX dll and exposing functionality to put an administrative interface on top of it. Finally, you need to use string handling functions that are faster than those that VB gives you, as this will be the biggest time-sink for you. I found a string class somewhere (might have been on the forums here-will check when I'm on my other machine) that smokes compared to VB. Some stuff to get you started:
Attached is the current state of my game-loop code. I've moved to implementing the object structures and can't test this until I'm done, so it might not work at all as written now. Note also that I'm writing VB directly over the C source, so it isn't organized to my taste yet, but you will get more out of it if you can read C.
BTW, if you use any of the code in the example, you will need to comply with the CircleMud license, which can be found here:
Reply With Quote
): VB will work just fine for a low-client count server.
Originally Posted by azteched
