Just a suggestion...
Do you guys think you could implement a Cookie for every BNLS packet? I know it seems useless to a lot of people, but it would save me a lot of work. Its easier to organize a single BNLS socket with cookies than without. Things such as BNLS_CREATEACCOUNT and BNLS_CHOOSENLSREVISION for starters, but it would be really nice to have them all cookie'd ;-D

If not, I would like some assistance ><

Most new messages are being implemented with some sort of cookie value echoed back in the response.

BNLS_CHOOSENLSREVISION is deprecated; you should be using BNLS_VERSIONCHECKEX2 instead.

The reason why the "NLS"-related functions do not have a cookie right now is that there is some state with them associated server-side (all of the other BNLS messages are for the most part stateless).  For the moment, the recommended way to work around this limitation is to process requests to BNLS regarding these messages sequentially with a queue of requests that you would like to send, sending a new request after you get the response to the last sent request.

Yeah see thats my issue. The connection class I created allows for multiple connections to work together simultaneously. And at the moment, its no problem because I am using sub-classed BNLS sockets as well. The reason I want to use single-socket BNLS is because you have it limited to 7 connections per ip (understandable). Why exactly can't you add Cookies to the NLS packets though... I know you gave the reason, but it doesn't make sense to me in the way you put it. Also, if you are planning on adding cookies, when can I expect to see them?

Thx

The reason is that BNLS needs to keep track of the result of various internal calculations used for "NLS" style logon for many of the "NLS" related messages that have two steps involved in them.  In other words, for many of those messages, there are intermediate values that are generated as part of the first message (but not sent to the BNLS client) that BNLS needs in order to generate a proper response to the second message.  There is currently no provision in BNLS to store more than one instance of this intermediate state data per connection.  While this certainly not an insurmountable problem to solve, it does require a nontrivial amount of restructuring how BNLS handles requests and is thus not so simple to do as to just slap on an additional parameter to one of the stateless BNLS requests and echo it back to BNLS clients.

At some point, I am planning on refactoring much of BNLS to operate in a cleaner fashion internally, and that would be the most likely point at which I would add support for things like multiple "NLS" contexts per connection.  At this point, though, I do not see a whole lot of value in rewriting something for a patch release that is already planned to be redone at a later date anyway (and in a more architecturally correct way).  There is currently no hard ETA that I can give you on when that might happen, as it depends on how much time I am willing to devote to enhancing BNLS as opposed to working on other projects in my free time.

It is, however, on the list of things to do at some point, along with features like support for running version checks for legacy products (such as Diablo).

By executing logon requests in sequence via a client-side queue of requests, you should still be able to achieve what you are looking for in the short term (although at a performance penalty relative to how many concurrent logons you are making in a short time period).

Note that the ability to create a large number of extraneous connections to BNLS for operations that could be completed with just one connection is a deprecated feature that is subject to further restrictions (or removal) at a later date, if for no other reason than that it is simply a waste of resources to not use a single BNLS connection.

I agree 100%, but like you said, why spend time coding something if the infrastructure is going to change... Anyways, I don't see any restrictions with using BNLS for non NLS products (OLS?) because the majority of the packets that I need do have cookies. However, if I were to want to implement the NLS products into my client (which I do want to do), I would need to redo my entire connection class. So I guess its really up to which one of us is willing to work on our projects, though it seems at this point I'm more willing than you ;-p

Whos writing their checkrevisions anyhow? Have you spoken with them? Or are you just as oblivious as the rest of us as to the whereabouts of the Battle.net coders. I have a feeling you may know something because of your previous statements ;-p (no real accusations of course.)
Thx

Well, let me restate it to better put things in perspective.

There are two branches of BNLS; the legacy branch (which is the code running on the public BNLS instance today), and the "new feature" branch.  I don't have a whole lot of desire to backport things like support for multiple "NLS" contexts per client session to the old legacy branch and its architecture, as that is essentially old, "dead" code that is in maintenance mode only.  Some things are isolated in a way that makes them relatively easily swappable (such as version check management) in the old architecture, and others are not (such as "NLS" contexts per connection).  The architecture on which the BNLS instance that is currently deployed today is based on will eventually be completely replaced by what is being developed on the "new feature" branch.

Time I spend backporting new features to the old branch is essentially just purely wasted time, as that is code that is going to completely go away anyway.  As a result, only service-impacting bugfixes and the like are being deployed to the legacy codebase at this time.  The primary reason for wanting to rearchitect much of the service's internals is due to the inevitable scope creep that has occured from the original design specifications of BNLS (originally a fairly small and unmanaged, fast service designed exclusively to support "NLS" style logon management for clients that did not individually make more than one connection to Battle.net simultaneously) and the current implementation and feature-set of BNLS today.  While the current architecture performs well, it is unfortunately not so well suited to certain classes of new feature development, and has its own fair share of "skeletons in the closet" (such as how "NLS" style logons are handled internally).  It is simply needing to be redone to better match how BNLS is used today, and how it is likely to be used in the future, going forward.

Now, the "new feature" branch is a significant rearchitecturing of much of the internals of BNLS, and is thus not something that is going to be quickly rushed out.  Additionally, I don't have unlimited time that I am willing (or able) to devote to this project, and the time I do have is significantly dependant on outside circumstances such as how busy work is, or other things of that nature that tend to vary a great deal on a day-to-day or week-to-week basis.

Given this, I can't really give any firm estimates as to when significant new features might be released.