Websockets
-
@Igor-Neuhold Hmm, then that means the binary is compiled for your computer rather than for the Omega. It was able to run on the Omega without any issue?
-
2 errors show up, same like when using binaryjs or ws, but with those 2 libs sockets get disconnected immediately after connection, with socket.io i get 2 warnings that 2 modules are not ELF executable for MIPS but i've read socket.io has a bunch of fallbacks so i guess that's the reason why it works. I can even send and read binary data.
But the biggest problem is that socket.io takes up to 4.1MB
-
@Igor-Neuhold Ah, i see. Socket.io is probably falling back to long-polling to accomplish the same tasks. Can you try to removing the binary files (that's not ELF executable for MIPS) to see if that reduces the module size by any significant amount?
-
around 100kb less, not enough. I would need to figure out exactly to what socket.io falls back to and remove everything else so it has a reasonable size.
-
@Igor-Neuhold Looking at the dependency tree of
socket.io
, it seems to be dependent onws
. How big was ws when you were using it? Also when i look at the dependencies ofws
, it's dependent onoptions
andultron
, both are 100% native node applications, so i'm not quite sure which package is dependent on theutf-8-validate
module that was giving the error.
-
just ws are ~800kb
bufferutil and utf-8-validate throws as not ELF exec...
and ws disconnects user after it receives connected event, i'm guessing that socket.io fallsback to something else?
-
@Igor-Neuhold Yeah, i think it should be the
socket.io
that's falling back to long polling. It seems like you will need to change some code to tellsocket.io
to start directly with long polling instead of tryingws
first. This way you will be able to removews
entirely and save 800kb of space.
-
it would be better to avoid socket.io and use ws compiled for MIPS, i just have no idea how to do that. Just saying if we had working ws and have an option to avoid socket.io we would save 3.2MB
-
@Igor-Neuhold Can you isolate the source code for
bufferutil
andutf-8-validate
?
-
you mean in ws?
I'm not sure that's the way to go. Can't you just compile ws for MIPS or something?
as for storage I guess 4mb ain't so bad with some external data device
-
@Igor-Neuhold
ws
is compiled bynpm
, but in order to cross-compile them for the Omega we will need to get the source code and use the cross-compile toolchain to compile them (because we don't havenpm-gyp
on the Omega).
-
maybe this can help: http://fibasile.github.io/new-node-modules.html
-
@Igor-Neuhold Thanks for sharing! I will test them out
-
I'm looking forward to seeing
ws
working with Node.js on Onion
-
@Sergiy-Kyrylkov Do the packages listed here work? http://fibasile.github.io/new-node-modules.html
-
@Boken-Lin I don't know. We cancelled our Onion orders until Node.js is confirmed to work with the libraries we need (Mongoose, ws). Also Node.js 0.10 has a regression which breaks our code on Intel Edison, so we cannot use anything less then 0.12
-
Hi @Sergiy-Kyrylkov, these are all functions we are in the process of working on. As soon as we have them ready, we will let you know. Also, are you thinking about running MongoDB on the Omega itself? Or are you going to be using Mongoose to access MongoDB on a server?
-
@Boken-Lin No, we need just the Mongoose and ws. These two libraries have native components.
-
@Sergiy-Kyrylkov I see. Just running mongoose shouldn't be an issue. We just need to get them to cross-compile properly on the Omega. Please stay tuned for that!