Well, I hate programming for Bnet anymore.
But, I was looking at JBLS's code the other day.
After dusting a few feet of dirt off of it. I realized, the code is really, REALLY fucking ugly.
So god dammen many useless features. Shit that nobody needs to have. JBLS should just run in the background, no interface at all. A daemon.
So, I *may* end up almost completely re-writing it.
Which is where you all come in, Brainstorm time.
Few core features:
Async packet handling:
-Set number of worker threads for entire server, or set number per connection.
-Per connection:
Can cause an ungodly amount of threads [100 connections * 5 per connection ...]
Would cause no possible cross-connection backup [lag]
-Per server:
Low thread count [25 worker threads should be fine, if that]
Possibility of a queue [lag]
Personally i'm for the per server route.
Checkrevision:
-'Intelligent' guessing. AE: packet 0x09 you only get the archive number. Take a guess based on product for the current one in use by battle.net.
-Multi-threaded, The MAIN lag time of JBLS is in the crev, Namely lockdown. But having 2-3 instances of each crev classes loaded means 3 crevs can be run at once. Once again this could be set num per server, or one instance per connection.
-Lockdown, Dear god this needs to be improved. we NEED a faster way of loading the files. A more efficient way. JBLS with all files loaded into memory for Lockdown uses 85~mbs of memory. Unacceptable.
-Inheratance, v1, v2, and v3 of checkrevivion are all exactly the same, cept, v2 introduced padding, v3 introduced 64-bit unsigned ints. Having one core v1 that handles u64s and simply replacing the readFile() function. [thats what its called now] would save a SHITLOAD of room code wise.
Administration:
I, Will leave that to the outside user. I *might* make JBLS extensible. AE: make helper functions [reloadConfig, setVerByte, blah blah blah] leave others to make there own plugins for it. Oh, hell, I could make the eintire server selfcontained and have things like config files, statistics, etc.. in plugins.
Main thing that pissed me off about working on JBLS back in the day was that I was stupid, I jsut kept adding shit into it. I never really defined the CORE of JBLS and had everything round it. [Though the code I ave now, unreleased, is a bit better at doing that]
So, should I make it plugin sytyle ala JavaOp? This then involves the question of threadding. If a plugin registers that it will handle packet X, and then a client sends 2 X's in a row. The threads would split, 2 would pickup the X packet. Race for the single instance of the handler, And then have to queueup again. Is this big enough of a concern that I should do something about it? How about, when a plugin registers a packet handler, each worker thread createa a subthread. Then again we get into an ungodly ammount of threads.
I know there is a simple way to do this, I jsut am not seeing it.
Also 1/2 this thread was me talking to myself, but feel free to chime in.
As you all know my MAJOR downfall is planning things out to be clean/efficient.
