Restarting from Scratch!

[Kp]

What's BNLS RCRS?  Or do I have the wrong idea on what it is?

It's a Java-based stripped-down BNLS rip-off.  Among its failings:
* Uses text protocol (think http or BNCS chat, rather than bnbinary / BNLS)
* Written in Java (eww!)
* Cannot perform many of the operations for which BNLS is most useful

[Skywing]

What's BNLS RCRS? Or do I have the wrong idea on what it is?

RCRS stands for Remote Check Revision Server, its a plaintext server iago wrote for JavaOp and others to use its pretty neat.

It's an opensource server to do the versioning for logon so you don't need hashfiles or version information locally.  It doesn't (and I refuse to) touch cdkeys and  passwords, because that's just asking for trouble.  It's also decentralized, I have two stable servers, and anybody can run their own, so no chance in them being taken down.

In any case, I don't see what that has to do with this thread.

If you have to know the set of servers ahead of time, it's still rather centralized, so I don't think you are truly solving that problem.

Consider that most end users will use the defaults, which provides well-defined points of failure.


MindFyre: I'll give a quick runthrough of how BC4 is being written, in case you want to borrow ideas:

The primary design goals are performance and remote access - what I came up with is...

- A dedicated service that maintains connections to various types of chat networks, and logs events to pass on to clients connecting to the service (with backchat).
- A network-based user interface that does not maintain connections to chat services directly; instead it connects to the dedicated service, receives backchat, and interacts with chat services through the dedicated service.

The important thing here is that the user interface is completely isolated from the backend (user interface operations tend to be very slow compared to most work the backend will be doing).

The service/backend borrows some of it's internal design from BNLS -- there's a single network thread that controls all active connections and maintains state, and a variable number of worker threads (typically but not necessarily one per processor).  Only the network thread directly reads or writes 'state' data, so no locks are required.  All 'expensive' operations are done asynchronously on worker threads (only trivial calculations and state management are done on the network thread).

No blocking operations are permitted in the network thread, as it must be responsive at all times to deal with network events.  DNS operations are performed asynchronously using a dedicated resolver thread (due to a lack of true asynchronous DNS lookup calls in Win32).  All network I/O is overlapped.

Communication between worker-, network- and DNS-resolver- threads is done via I/O completion ports (BNLS used APCs).  I'm not sure what the best analogue of this would be in .NET-land.

BNLS is fairly good proof that the architecture scales reasonably well.

[iago]

What's BNLS RCRS? Or do I have the wrong idea on what it is?

It's a Java-based stripped-down BNLS rip-off. Among its failings:
* Uses text protocol (think http or BNCS chat, rather than bnbinary / BNLS)
* Written in Java (eww!)
* Cannot perform many of the operations for which BNLS is most useful

I don't see a problem with any of those:
* Sends less bytes than equivilant BNLS.
* It's portable.  We run it on Linux servers.
* Really? I thought the most useful parts were the lack of requiring hashfiles and the lack of having to make changes when the game's version changes.  And those are what I do.  Sending cdkey and password anywhere in plaintext is just stupid, yet BNLS encourages that?

In any case, I wrote it for myself, and I don't care what people think/who uses it.  I never bothered posting here, or on any forum, because it doesn't matter.

[MyndFyre]

even if it's compiled JIT once it's still interpreted i.e interpreted  = non native just to keep it simple for you.

Maybe I'm not keeping it simple enough for you.  The JITter compiles the output to native code.  The native code is reused whenever the just-JITted function is called again.  No interpretation necessary.  No JITting necessary.  If I run NGEN.exe on an assembly, it's not JITted at all when it gets to my client.  Learn what you're talking about.

And this is also related to your original question in that it's an architectural issue selecting a language based on it's qualities and you also said you wanted fexibility and high performance and i therefore suggested a more appropriate language for high performance applications.

I disagree; language is not part of the architecture, it's part of the requirements.  Often, in the real world, there are reasons for choosing one language or another.  If my specification is that I'm using .NET and also going for performance, then we look at what performance bottlenecks might come up.  If you're working for a business and they want a solution that will integrate with a .NET Web Service on their servers, but they also want other parts to be high-performance, you'll probably choose C#, because the Web Service is already built-in for you, and you can achieve good performance with it.  You wouldn't sit there and argue with them about using C++ because its performance is better, unless you wanted to get fired.

Skywing: thank you.  I'll look at how I might be able to work that into my plans.

[hismajesty]

What's BNLS RCRS? Or do I have the wrong idea on what it is?

It's a Java-based stripped-down BNLS rip-off. Among its failings:
* Uses text protocol (think http or BNCS chat, rather than bnbinary / BNLS)
* Written in Java (eww!)
* Cannot perform many of the operations for which BNLS is most useful

Of course it can't do many of the things BNLS does, it wasn't designed to - hence the name Remote Check Revision Server. There was another individual who extended some of iago's code and made a BNLS-clone in Java, following the same protocol and such and allowing current BNLS bots to work with it. Only difference is it's open source, written in Java - and, thus, cross platform.

[OnlyMeat]

DNS operations are performed asynchronously using a dedicated resolver thread (due to a lack of true asynchronous DNS lookup calls in Win32).  All network I/O is overlapped.

I have'nt had a problem with async win32 dns api calls they seem to their job fine why are they not truly async?

I use WSAAsyncGetHostByAddr etc.

[Skywing]

DNS operations are performed asynchronously using a dedicated resolver thread (due to a lack of true asynchronous DNS lookup calls in Win32).  All network I/O is overlapped.

I have'nt had a problem with async win32 dns api calls they seem to their job fine why are they not truly async?

I use WSAAsyncGetHostByAddr etc.

If you look at how those work under the hood, you'll see that ws2_32 creates it's own worker thread and uses (synchronous) gethostbyname, then posts a message to you.

I use I/O completion ports, which are incompatible with window messages (not possible to wait for both a window message and a completion packet at the same time in the same thread).

Additionally, the various WSAAsyncGetXByY functions don't support IPv6 -- I have native IPv6 support everywhere, which requires support for hostnames with IPv6 addresses associated.

MSDN also recommends against using WSAAsyncGetXByY:

WSAAsyncGetHostByName
The WSAAsyncGetHostByName function asynchronously retrieves host information that corresponds to a host name.

Note  The WSAAsyncGetHostByName function is not designed to provide parallel resolution of several names. Therefore, applications that issue several requests should not expect them to be executed concurrently. Alternatively, applications can start another thread and use the getaddrinfo function to resolve names in an IP-version agnostic manner. Developers creating Windows Sockets 2 applications are urged to use the getaddrinfo function to enable smooth transition to IPv6 compatibility.

[OnlyMeat]

even if it's compiled JIT once it's still interpreted i.e interpreted  = non native just to keep it simple for you.

Maybe I'm not keeping it simple enough for you.  The JITter compiles the output to native code.  The native code is reused whenever the just-JITted function is called again.  No interpretation necessary.  No JITting necessary.  If I run NGEN.exe on an assembly, it's not JITted at all when it gets to my client.  Learn what you're talking about.

Yes im not a .net expert but i do know how the JIT process works in .net, the JIT occurs every first time a method is run in each session which means caching only takes place during the application lifetime, as soon as you run the application again the same process occurs BANG performance hit after performance hit. Therefore it's effectively interpreted everytime it's run ( per method ) when the MSIL is translated to native. Learn what you are talking about.

And this is also related to your original question in that it's an architectural issue selecting a language based on it's qualities and you also said you wanted fexibility and high performance and i therefore suggested a more appropriate language for high performance applications.

I disagree; language is not part of the architecture, it's part of the requirements.  Often, in the real world, there are reasons for choosing one language or another.  If my specification is that I'm using .NET and also going for performance, then we look at what performance bottlenecks might come up.  If you're working for a business and they want a solution that will integrate with a .NET Web Service on their servers, but they also want other parts to be high-performance, you'll probably choose C#, because the Web Service is already built-in for you, and you can achieve good performance with it.  You wouldn't sit there and argue with them about using C++ because its performance is better, unless you wanted to get fired.

I disagree i think certain architectures are not possible in all languages for instance i was working on a software contract developing a generic data transformation for various file formats, the original language was going to be vb 6.0, but after much discussion it was decided vb's threading model was not appropriate for the transformation of multiple formats simitanously therefore a new language was selected with a more efficient threading model - 'C++'.

As a contract software developer working in the 'real world' i have practical experience of these issues. of course solutions can be developed completely independently of the  software language but when the need arises for specific performance, scalability and other qualities then certain languages meet these requirements better than others. and this is infact an architectural issue.

[shadypalm88]

Hey, kind of getting back to the original topic, I think I'll throw in my two cents, as I thought about a project like this previously.

Basically what you would like to do, I take it, is provide good enough abstraction that your app can be used for chat and IM protocols.  Even within the two chat protocols you're considering (BNCS & IRC), there are some fundamental differences.  On Battle.net, for example, you can only be in one channel at any given time, but this doesn't hold true for IRC (if I recall... I never used IRC much).  Not to mention that the general auth/login procedures are very different.  You'll need some sort of mechanism(s) for describing the limitations of each particular protocol.

Then you have IM thrown into the mix.  While all the IM services you listed support group chat, these are different in that (again, IIRC, YMMV, etc.) you normally don't create a globally accessible "channel", but rather invite people to conversations.  Although, if you treat every chat channel and IM conversation as the same type of "channel", headaches can be reduced.

And as far as commands go, you'll run into trouble with those between services.  Unless, of course, you provide methods to create those commands (e.g., ban on BNCS/IRC will run a /ban, but on, say, MSN, will block the user).

If it were my project, I would have a "Service" class that all chat/IM services would derive from; possibly generic Chat and IM classes that the services would derive from instead.  Conversations - regardless of whether they are actually channels or IM convos - would all be represented by the same class.  (I'm of course assuming you're thinking OOP, since you're using .NET.)

But I'm pretty new to all this, and I'm sure you can come up with something better.  I am interested in how you actually implement it, though.