Eluna + luasocket

[xardion]

DISCLAIMER: For reasons of stability and security, adding socket support to the Eluna engine is not recommended. If that does not deter you, by all means proceed.

This started for me when I wanted to set up an IRC bridge, but there are plenty of other reasons why you may want or need to open a socket in a Lua script.  Obviously, just installing LuaSocket through the usual means (downloading the source & make install, luarocks, etc) isn't going to work because those approaches are intended for a system install of Lua.  Eluna has its own built-in Lua engine, so LuaSocket has to be installed with that in mind.  Additionally, LuaSocket has native components written in C, so just adding the library paths to the package.path will likely be insufficient, with one caveat: if your MaNGOS/cMaNGOS/Trinty server is built with dynamic script support, you may actually be able to do exactly that.  However, I didn't test this, so I'm not certain of its efficacy.  These instructions assume that you're compiling with statically built scripts, with no dynamic library loading support.  If your core is compiled with dynamic library support and you want to try that approach, skip to STEP 4 (specifically where it mentions dynamic library support in bold) after installing LuaSocket on your server (build it against Lua 5.2 if you do this).

I did this with ElunaTrinityWotlk and LuaSocket 3.0rc1 on Linux, you'll have to modify this if you're on Windows or OS X, or if you want to use the latest LuaSocket master as the module names have changed slightly, and additional ones have been added. YMMV on cMaNGOS and MaNGOS, but as they all use cmake, it should work with them as well.

If you aren't using your own fork of the appropriate (cMaNGOS/MaNGOS/Trinity)+Eluna codebase, or at the very least using your own branch, you should do this before proceeding.  This will involve making code changes to the lualib in the core, and keeping up with updates after doing this will be difficult if you aren't using your own fork or branch.

STEP 1: Copy the C source and header files (src/*.[ch]) from LuaSocket into the dep/lualib directory in your server source root, and then remove the inappropriate platform specific files: wsocket.[ch] if you're on Linux/OSX (since these files are for Windows), usocket.[ch] for Windows. You COULD alter the next step to be platform-aware instead, but this seems like overkill.

STEP 2: Add the following lines to the bottom of dep/lualib/CMakeLists.txt:

add_definitions(-DLUASOCKET_NODEBUG)
add_definitions(-DLUA_COMPAT_MODULE)
add_definitions(-DLUA_USE_POSIX)
add_definitions(-DLUASOCKET_API='__attribute__\(\(visibility\(\"default\"\)\)\)')
add_definitions(-DUNIX_API='__attribute__\(\(visibility\(\"default\"\)\)\)')
add_definitions(-DMIME_API='__attribute__\(\(visibility\(\"default\"\)\)\)')

This is Linux specific, OS X and Windows require different definitions here.  You can glean these from the LuaSocket Makefiles.

STEP 3: Apply the following patch at the root of your source tree (it only changes dep/lualib/linit.c):

diff --git a/dep/lualib/linit.c b/dep/lualib/linit.c
index c1a3830..12e6c1e 100644
--- a/dep/lualib/linit.c
+++ b/dep/lualib/linit.c
@@ -20,6 +20,8 @@

 #include "lualib.h"
 #include "lauxlib.h"
+#include "mime.h"
+#include "luasocket.h"


 /*
@@ -45,6 +47,8 @@ static const luaL_Reg loadedlibs[] = {
 ** these libs are preloaded and must be required before used
 */
 static const luaL_Reg preloadedlibs[] = {
+  {"mime.core", luaopen_mime_core},
+  {"socket.core", luaopen_socket_core},
   {NULL, NULL}
 };

You'll probably need to apply this using patch -p1 , or you could make the changes by hand.  It's just adding 4 lines.

STEP 3: Build your server.

STEP 4: Create a .lib directory in your Eluna.ScriptPath (on Windows you'll also want to set the hidden attribute) if you want to keep all of your Lua code and libraries in the script path.  Eluna doesn't automatically load scripts in hidden directories.  Or, you could use a path external to your script path.  Your choice.  Either way, you'll need to copy the .lua files from the LuaSocket source into this directory, with socket.lua, mime.lua, and ltn12.lua the directory itself, and all of the other .lua files in a socket subdirectory within the library directory you used.  Again, this will be slightly different if you're using the LuaSocket master branch instead of 3.0rc1, and you'll need to look at the Makefile to see how to place those files.  In either case, any Lua scripts that need to use LuaSocket will have to have their path modified before doing a require("socket").  Add the following to the top of the script:

package.path = package.path .. ';lua_scripts/.lib/?.lua;lua_scripts/.lib/?/init.lua'

Change lua_scripts/.lib if appropriate.  If you installed LuaSocket on your system and are using a core with dynamic library support, you'll want to use this instead:

package.path = package.path .. ';/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.2/?.lua;/usr/local/lib/lua/5.2/?/init.lua'

This assumes you're on Linux or OS X and are using the default prefix.  If you're on Windows, or you're using a different prefix, these paths will obviously be different.

Modifying the package.path in this fashion will also allow you to use other Lua libraries without putting them in your Eluna.ScriptPath.  This is desirable when using libraries that assume a specific require order and throw errors when Eluna tries to autoload every Lua file it finds in the Elnua.ScriptPath.

[Foereaper]

This might be a bit late, but I am currently working on implementing LuaSocket and LuaSec as officially supported modules for Eluna

[Foereaper]

Xardion, I primarily do windows development, and I have that working properly, would you be interested in helping me out with the Linux side of things? Primarily testing, as I don't have a Linux test environment set up atm 

[xardion]

I mostly just threw this out as a "it's possible to do this if you need it" because I had done it for my own purposes (IRC bridge).  I haven't touched it in months, mainly because I haven't had time and it works for what I needed it for.  My suggestion is to just spin up a Linux VM (VirtualBox is free and works perfectly) and test it with that.  That said, if you can't do that, feel free to shoot me what you have and I'll take a look when I can.