In rebuttal:
1) The actual netcode is encapsulated pretty well at this point. Most of zone/world did not have to change with the new netcode (except that I esstenially renamed APPLAYER to EQApplicationPacket). I basically rewrote the lower level (and tried to preserve the API structure as made sense) and the plugged it in and tweaked it.
2) I completely agree. But this is a -major- undertaking. The new eqcollector (replaced packet collector) is very modular and supports the use of plugins for processing the packets. The major issue here is the way windows uses DLL's (at least in vs.*). In unix a shared object is brought in to the memory space of the running executable and can directly call the functions in there. Not so in windows. Doing this would involve putting -everything- that might need to be called into a series of DLL's, which is of course doable.
3) I agree, in principle. But, you'll get a very small return on the time investment. Mysql is the most popular opensource database followed, probably, by PostgreSQL (which I prefer). I don't forsee anyone using Oracle or Sybase or SqlServer for a eqemu backend, it's either outright piracy or it's cost prohibitive.
4) First of all, to me this is not "network code". This is application transport level (i.e. spawn struct, player profile struct, etc). If you are talking about a preprocessed ML for generating C/C++ structs/functions, yeah that'd be great. I started on this as well, at least in theory. Having each object know how to build the packets that it's interested in. That way it's completely encapsulated and can be changed without affecting external code. Having a ML to generate those methods would be great. I have concerns about having it purely dynamic during runtime. It would be very hard to do effeciently on the server (clients have it easy). Remember, multiple the work the client has to do in these cases by 10, 20, 80, 100, however many people are on the server. More work = more lag = more instability.
5) I kind of agree with this. More threads isn't always a good thing. More to manage, more to join back in, more to coordinate. And as far a taking advantage of a SMP machine, if you have multiple people in multiple zones, you already are doing so. Adding more threads may not help, plus I'd wager a lot of things done per client can't reallt be done in parallel outside of slower database type things (like saving).
I'll add #6. There are a lot bigger issues with the eqemu code (bugs, stability issues, live compat, etc) that I feel a lot of this time and energy could be focused on.
I'm not trying to be a nay-sayer, but more of a realist. These are great ideas and things that I agree with on principle. Some of them may not be worth the effort when you look at the bang you'll get for your time/effort -buck.
|
Threaded Mode
