nwnx_ruby offspin: nwnx_ice, multi-language RPC-interface

[elven]

@deprecated
nwnx-ice is flagged (as far as I am concerned) as deprecated. Meaning you shouldn't use it for new projects. Instead, use the much more current and actually maintained nwnx_jvm, which you can find in the core repository!

For those still caring for nwnx_ice, you can find all the bits and blobs on github: https://github.com/niv/nwnx-ice

For kicks, I've created a NWNX2-plugin that implements ICE as a RPC interface to various languages.

It is workable, stable, and (at least with Java) performs well enough to be quite useable (30k calls/second on local connection).

The API is not really spec'ced out, for now NWScript calls are exported as-is in a somewhat normalised version.

For now, there is only a linux version.

To give you an idea on how the implementation works:
- You call ICE_EVENT("name"); from NWScript in a regular event handler (for example, onPlayerEnter)
- nwnx_ice does a RPC call to the backend (which you will be writing in a supported language of your choice)
- Your backend does as many sync RPC calls (see the linked API above) as it would like, processing the event as needed.
- Your event handler returns, and the script ends.

You can get as fancy in the backend as you would want, as long as you sheperd your NWScript calls in a orderly fasion into those event windows.

I'd like to hear if there is some interest in this, and if so, what you would use it for. I am open for any suggestions.

Regards, elven

[elven]

With the autogenerated ICE java classes, the following example Scala (a very nice JVM language) code is fully functional:

[acaos]

I'd definitely be interested in this. We have a number of CPU sucking things on HG (such as our new item randomization system) which would be helped greatly by the ability to use more advanced language features (e.g. lists and dictionaries).

Acaos

[elven]

For anyone tech-savvy anough to fiddle with NWNX and C++, I have made a prelimenary dev version available at

http://git.swordcoast.net/?p=nwn/elven/nwnxice.git;a=summary

You will need git to check it out and keep up to date (or just click "tree" -> "snapshot" at the above link).

I didn't publish in nwnx2-dev because I can't for the life of me figure out how to do comfortable branching with svn.

Quickie Howto:

cd ~/your/path/to/nwnx2/trunk/plugins/
git clone git://git.swordcoast.net/nwn/elven/nwnxice.git
cd nwnxice

To build, you will need zeroc ice-dev installed, and preferably Java to test things.

You can generate the API docs with make doc, the java bindings with make client (they'll be in java/).

There isn't much/any other documentation (yet), but you can contact me on Jabber (elven@swordcoast.net) or IRC (irc.nwn2source.net #nwn2cr).

I'll publish the Scala framework I threw together later on too.

[elven]

There isn't any configuration yet in the ini. Connect strings are hardcoded in NWNXICE.cpp - client events get sent to localhost port 5222, NWScript API listens on 0.0.0.0:5223 - so be careful with those routed nets.

There is lots of documentation on how to write ICE clients in the official pdf at zeroc.com, but I'll gladly help out too if it means I get some people and testers using this thing.

If you don't know what a mutex is and how to deal with it, don't bother yet downloading it.

[elven]

I have commited some sample java code, and a test module for your convenience. (path java/ inside the repository).

You will need to create the java classes before building ("make client").

To compile the java code, do not forget to add Ice.jar to your classpath.

javac -cp /path/to/Ice.jar:. *.java

Note that you cannot nest ICE_EVENT(); invocations. Running a NWNX module that will directly call nwscript->ice as a result from a NWScript call/action will deadlock the server. Example: nwnx_chat.

This means assigning speakString() to a object from within ICE will directly trigger ICE again (which is already busing waiting for the first request) and deadlock. The workaround for this is to use NWNXSpeakToChannel() from inc_nwnx_chat. (This segfaults for me, but is probably a different problem.)

Except that, all is peachy.

The assign()/token() methods are a workaround of not having AssignCommand() exported, and is described in greater detail here.

Documentation is still lacking, as it is. ;)

If you try it out, please contact me.

Regards, elven

[elven]

Proof that it works. :shock:

[elven]

Just to let you know, the segfault for chat is fixed, some enums were added, and various other things. You can now nest invocations, so directly using other nwnx plugin callbacks (I only know of CHAT that works that way though) is not a problem anymore.

Regards.

[Fireboar]

This is very interesting indeed, but documentation is lacking and having never touched Ice before I would pretty much be flailing around in the dark.

Maybe when I get a weekend or so.

Also, would this work well in a multiple server environment? Does this improve the load at all when running scripts that just use a series of NWScript commands? I'm sure it improves the load when doing things like string operations (which are sorely lacking in NWN).

[elven]

Ice is pretty much like any "enterprise" RPC library out there. You define the interface in an extra file (.ice slice definition), and your slice compiler (slice2java, for eample) generates some proxy classes, which will take care of all message passing/marshalling, etc. Ice does all the networking and connection handling for you, of course.

There is some example code inside the repository under java/, which should anyone experienced with java development get started quickly.

Either way, some considerable time investment is needed to get some use out of this.

You can always catch me on IRC or Jabber and I'll be glad to help in setting things up and answering questions.


I haven't given multiple servers much thought, but you can of course hack ICE to send along a unique server id and handle things in one place, though I don't see the advantage in that. You'd have object IDs from multiple servers arriving at the same backend. A much cleaner way would be to use ICE or a custom interface to make instances communicate with each other. ICE even has support for such things (similar to JGroups, I believe, which would be another option), but I haven't looked at that yet.

I chose ICE, because it is trivially simple to implement and has lanugage bindings for both C++ and Java, C#, Ruby, Python, and a few other languages, so people can pick what they like.

Performance: Depends. Yes, it improves load considerably, even though individual NWScript calls are many orders of magnitude slower than native. You just really need to know how to design things well.

I didn't write this for performance reasons, though. The main advantage of all this crud is language features and library support, not performance. You can go wild with your imagination on that one, don't stop at string handling. I'm currently thinking about a rework of the rather crude AI. I've written a direct XMPP/ICQ interface. Hibernate ORM mappings.

This is the framework I am working on (and running it in production already) - written in Scala, which is a wickedly cool JVM language. You can see some temporary example plugins here.

Edit, re: performance: The footsteps script above, which runs every second, finishes in under 12 ms at the worst case (50 creatures). That's not too shabby, considering that the magic missile nss takes what, 20ms?

[elven]

Lo and behold, a README!.

[Fireboar]

Wonderful! I'll see what can be done with this when I get round to it.

[PlasmaJohn]

GPL3? *shudders*

Well that's a shame. Starting with 2.1 and significantly broadened in 3.0, the FSF became real militant about their various agendas. I personally would avoid using either of those until I had access to a clear and rigorous legal analysis. If I trust my own interpretation, then potentially I would be responsible for any legal damages against people who used my code, but then I am not a lawyer.

[elven]

[PlasmaJohn]

Thanks!