Messages

* HdxBmx27 isn't explaining this correctly.

I'm agreeing that 1 worker per connection for the general things is good, Yes. BUT, the thing i'm thinking needs worker threads are the algorithms, CheckRevision mainly.

Ya, dropped a zero.
Still unacceptable neh?
Even with only 2 worker threads, that's 10s, 4 = 5s, 5 = 4s. I wouldn't go with more then 5.
You all get the point.

Do you not understand the point of this thread?
Its to get a GOOD design set.
95% of the things that use JBLS will not really care for async packet handling. So the way JBLS is now, [single threaded per user req-resp pairs], works fine. But im just thinking of things such as large algorithms [Checkrevision, SRP, not so much SHA] don't impede simple things. [ver byte retrieval, etc..]
Currently, all crevs are queus up in one line. So if 100 people request a crev at the same time.. the last guy is gunna wait a long ass time! [I think it was 200ms for v1, 200ms*100 = 20seconds]
This is all in the planning stage. I don't plan on actually writing anything till at the soonest sunday.
Also, the other main reason I wana do it is the shear uglyness of the code. But unless I have a good design, it'll just end up ugly again.

Do you realize how untrue that sounds? :P

Yes, I do, which is funny that its true.

Well, I got a new laptop[1.73Ghz x2, 2GB RAM, 250GB hdd, integrated nvidia N, 15.3", $250]

New New or Used new?

Only ben powered on 3 times before I handed over the cash, once by me, once by my friend and once by the guy who i got it from.

Somewhere I can buy a setup like that at that price?

Same place his friend got it -- off the back of a truck. :P

Actually, There is a rich dude in town, who has the hots for my friends grandma. So he buys her new laptops. She usually gets 2-3/week. She turns around and sells them for cheap.

Can cause an ungodly amount of threads [100 connections * 5 per connection ...]

Why so many threads per connection? :X

Just a random number for worker threads i pulled out of the air.

Well, I got a new laptop[1.73Ghz x2, 2GB RAM, 250GB hdd, integrated nvidia N, 15.3", $250]

New New or Used new?

Only ben powered on 3 times before I handed over the cash, once by me, once by my friend and once by the guy who i got it from.

I promise I won't say "I told you so."

You do realize that JBLS was made like 4 years before you were an itch in sun's groin... Anyways, I was kinda stupid back then. And up until now way to dammen lazy to do anything about it :P

[edit] On a productive note, I'd be interested in contributing to a project like this, but only if there's a source-control system, and I'm a committer :)

Prolly SF or Google Code. Use there SVN servers.
I'll prolly keep the core my-commit only. But have plugins open for you. [I am really leaning twards plugin based]

And ya, Ron I saw your async class a while back when you posted it. I'll look into it more when I get a free moment.

The main thing i'm looking for from anyone isn't code. Its ideas. I bad at making a nice efficient system in my head. So it never comes out right on paper.
~Hdx

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.

Well, I got a new laptop[1.73Ghz x2, 2GB RAM, 250GB hdd, integrated nvidia N, 15.3", $250]. And we have a long ass road trip this Saturday. [We're going to the beach to steal sand :P]
So I have like 3 hours to kill. [Aside from fucking with friends int he car :P] so I might setup a local PvPGN and get the differances patted down/documented.
Hell if I feel like it i'll prolly mod PvPGN to be more official. [Handle things properly]
And if you're just the luckiest person in the world.
I might release PvPGN.jar [moded version of the Battlenet jar for javaop]
Thats if you're REALLY REALLY luckey. and I get bored.
But, if you say you know C++ then jaba should be no problem. The main thing is memorizing all the classes. The JDK can be downloaded form sun's site, and you don't need and IDE. [Though if you want one I suggest Eclipse for cross platform stuff, or JCreator for windows only dev. {still the program should be cross platform the IDE itself isnt}]

I should bring my camera. Molly in a bikini = pwnage ;)
Oh, And Joe, you going to Pax?
~Hdx

Anyone ever bothered to document exactly what PVPGN does WRONG?
For one thing PVPGN is Open Source, someone could mod it to work CORRECTLY.
This is the main reason I hate PVPGN. They were just to lazy to make everything work properly, just if it worked with the client.

mm, <3 the unintentional layers affect.

We got the answer. It isn't a "mad gabs" style thing. Let me know if you want it.

What is it?

I havn't actually looked at all the data that is exposed to plugins.
Are Client/Server tokens and CDKey exposed?
Thats all you need.

Wouldn't it be better to move Warden stuff to Warden.jar?
I was in the middle of doing that before I got bored and wondered off.