alexstrat / simudp

NodeJS Socket.io/UDP proxy
10 stars 3 forks source link

socket.io missing #1

Closed vanous closed 10 years ago

vanous commented 10 years ago

Hello, i have been pulling my hair here...

after browserifying/bundling the simudp (dgram-browserify, socket.io always shows up as missing. I have tested everything i coud but developer console shows always the same:

GET http://mnaknmbehfkifpdfihbjplhcjicelfog/socket.io/1/?t=1381705314334

which points to: xhr.send(null); in bundle.js,

created by:

browserify -r dgram-browserify -r socket.io-client -o bundle.js

i have tried different ways to use the module, like:

browserify -r dgram-browserify:dgram -r socket.io-client -o bundle.js

etc. but still the same result. what am i doing wrong?

node.js v0.10.20 simudp 0.0.16 socket.io 0.9.16 browserify 2.34

thank you

Petr

edit: Chromium Version 29.0.1547.57 Debian jessie/sid (217859)

edit2: ok, it seems like it a boils down to

Socket.prototype.setBroadcast = function(arg) { throw new Error('not implemented'); };

as i do set the broadcast flag to true.

any chance to add this in?

i am looking at it but no idea how to help...

P.

alexstrat commented 10 years ago

after browserifying/bundling the simudp (dgram-browserify, socket.io always shows up as missing. I have tested everything i coud but developer console shows always the same:

GET http://mnaknmbehfkifpdfihbjplhcjicelfog/socket.io/1/?t=1381705314334

socket.io is not missing at all, since that's socket.io itself that is doing this request.

simudp requires a server part running (that is built on top of a socket.io sever) to work, but I guess you've started it (like described in readme). However, here, socket.io tries to connect to a server which address is mnaknmbehfkifpdfihbjplhcjicelfog: pretty weird for an address, but I guess that's because you are using simudp inside a chrome extension, aren't you ?

To solve that, I guess that's the best you can do for the moment is to specify the server address manually for each instantiation of simudp socket. Try something like that:

var socket = SimUDP.createSocket('udp4', 'localhost:8080'); // if the server is running on 'localhost:8080'

However, I'm just realizing that's not totally handy. For instance, when you are using a lib relying on dgram without simudp in mind. I'll try to find a solution for that, probably based on global options for simudp.

i have tried different ways to use the module, like: browserify -r dgram-browserify:dgram -r socket.io-client -o bundle.js

You absolutely don't need to require socket.io-client since it's bundled in dgram-browserify. And I guess that you don't need to -r dgram-browserify:dgram since, based on package name, browserify will understand that it should use dgram-browserify instead of dgram.

as i do set the broadcast flag to true.

any chance to add this in?

i am looking at it but no idea how to help...

It should not be too complicated to add. It might look like something like:

--- a/lib/server.js
+++ b/lib/server.js
@@ -105,6 +105,10 @@ Proxy.prototype.handleBind = function(client, bind) {
     });
   });

+  client.on('broadcast', function(msg) {
+    udp.setBroadcast(msg.flag);
+  });
+
   //bind error events
   udp.on('error', function(reason) {
     client.emit('error', reason);
diff --git a/lib/simudp.js b/lib/simudp.js
index 726552f..89aa4db 100644
--- a/lib/simudp.js
+++ b/lib/simudp.js
@@ -143,8 +143,8 @@ Socket.prototype.address = function() {

 // not implemented methods

-Socket.prototype.setBroadcast = function(arg) {
-  throw new Error('not implemented');
+Socket.prototype.setBroadcast = function(flag) {
+  this.sio.emit('broadcast', {flag: flag});
 };

 Socket.prototype.setTTL = function(arg) {
vanous commented 10 years ago

On Mon, Oct 14, 2013 at 10:27 AM, Alexandre Lacheze < notifications@github.com> wrote:

after browserifying/bundling the simudp (dgram-browserify, socket.ioalways shows up as missing. I have tested everything i coud but developer console shows always the same:

GET http://mnaknmbehfkifpdfihbjplhcjicelfog/socket.io/1/?t=1381705314334

socket.io is not missing at all, since that's socket.io itself that is doing this request.

simudp requires a server part running (that is built on top of a socket.iosever) to work, but I guess you've started it (like described in readme). However, here, socket.io tries to connect to a server which address is mnaknmbehfkifpdfihbjplhcjicelfog: pretty weird for an address, but I guess that's because you are using simudp inside a chrome extension, aren't you ?

To solve that, I guess that's the best you can do for the moment is to specify the server address manually for each instantiation of simudpsocket. Try something like that:

var socket = SimUDP.createSocket('udp4', 'localhost:8080'); // if the server is running on 'localhost:8080'

However, I'm just realizing that's not totally handy. For instance, when you are using a lib relying on dgram without simudp in mind. I'll try to find a solution for that, probably based on global options for simudp.

i have tried different ways to use the module, like: browserify -r dgram-browserify:dgram -r socket.io-client -o bundle.js

You absolutely don't need to require socket.io-client since it's bundled in dgram-browserify. And I guess that you don't need to -r dgram-browserify:dgram since, based on package name, browserify will understand that it should use dgram-browserify instead of dgram.

as i do set the broadcast flag to true.

any chance to add this in?

i am looking at it but no idea how to help...

Thank you for getting back to me! Later on last night i have realized that yes, the socket.io actually is loaded (i am not very familiar with the dev tool of chromium) and yes, indeed, i am trying to run it in as an extension, sorry for not being more specific. Now, when performing tests, i am not running it in a browser, as i understand that i need to get it working in node.js first.

As i have then added later on, the missing setBroadcast was the show stopper. I have tried to use the patch you sent, i have tried to modify it and elaborate on it but i couldn't get it to work. It silently does nothing for me. Please excuse my lame trial to understand and comment on the below. Interestingly enough, i am not getting even the "listening" signal.

Not sure what i am doing wrong, my code seems to run ok with dgram module, but not dgram-browserify or simudp module... see simple example of my code here: http://pastebin.com/B1CgCBut

thank you

Petr

alexstrat commented 10 years ago

Now, when performing tests, i am not running it in a browser, as i understand that i need to get it working in node.js first.

Hmm.. I did not express myself properly: you need to have 2 parts running. On one side you need to have a node.js server running the server-side part of simudp: it proxies socket.io messages to node.js's dgram. You can have an example of such a server in example/test.js. On the other side, you need to have the client-side part of simudp running in your browser and that will communicate with this server. An example of this client-side part is in example/index.html.

Note that you could run the client-side part of simudp in node.js since it uses socket.io-client working on both environment (you'd probably need to specify the server address since it can't "guess" it like done in browser). But, obviously, there is no reason doing that..

So my questions are: is http://pastebin.com/B1CgCBut running in browser or on node.js ? Where is the server-side code ?

vanous commented 10 years ago

On Tue, Oct 15, 2013 at 11:41 PM, Alexandre Lacheze < notifications@github.com> wrote:

Now, when performing tests, i am not running it in a browser, as i understand that i need to get it working in node.js first.

Hmm.. I did not express myself properly: you need to have 2 parts running. On one side you need to have a node.js server running the server-side part of simudp: it proxies socket.io messages to node.js's dgram. You can have an example of such a server in example/test.jshttps://github.com/alexstrat/simudp/blob/master/example/test.js. On the other side, you need to have the client-side part of simudprunning in your browser and that will communicate with this server. An example of this client-side part is in example/index.htmlhttps://github.com/alexstrat/simudp/blob/master/example/index.html#L10-43 .

Note that you could run the client-side part of simudp in node.js since it uses socket.io-client working on both environment (you'd probably need to specify the server address since it can't "guess" it like done in browser). But, obviously, there is no reason doing that..

So my questions are: is http://pastebin.com/B1CgCBut running in browser or on node.js ? Where is the server-side

Hi Alexandre,

i have been sitting on it here and just came to the conclusion you provided me with... i didn't realize server side was needed. I would like to completely eliminate it as i wish the user would install app from the store (or get online) and would not have to care about server side. Or is there a way for me to package it [server] with the app and launch it? I don't think i can... so this is a no go... i will probably have to drop it and go back to the multiplatform python/kivy alternative - although i really wanted to use browser environment... I will still try too investigate the new chrome http://developer.chrome.com/apps/socket.html API. It could perhaps even be possible to either use the chrome.socket or chrome native client API and proxy it to browserify environment ? :)

thank you for all your time

Petr

alexstrat commented 10 years ago

Ah okay, I started to guess that doing a standalone app was your original intent !

As you concluded, simudp is not the solution since, as far as I know, there is no way to package a node.js server in chrome app and to make it run. (nevertheless, I heard that chrome apps now supports C/C++ code, so maybe some crazy guys manage to port node.js to a chrome app, or do similar things).

The socket API of chrome is probably your eldorado.. But it is not flexible and convenient like dgram is. If you'are interested, I started writing something that tries to put a dgram-like API on top of chrome socket: https://github.com/alexstrat/chrome-udp-nodejs-socket but that's still experimental.

If you are building a desktop application (like you could do with kivy) but you'd prefer do it in node.js, you should have a look to http://appjs.com/

vanous commented 10 years ago

Hi,

well, just for your interest... i tried to use the chrome.socket API. i can send arbitrary UDP packets from browser extension now but UDP broadcasts do not work i need them as my discovery process depends on it). I think your chrome-udp-nodejs-socket project will face similar issue... i presume that broadcast flag needs to be set to the system networking stack and although chromium seems to have this in it's code, the api is missing such an option...

Petr

On Wed, Oct 16, 2013 at 12:15 AM, Alexandre Lacheze < notifications@github.com> wrote:

Ah okay, I started to guess that doing a standalone app was your original intent !

As you concluded, simudp is not the solution since, as far as I know, there is no way to package a node.js server in chrome app and to make it run. (nevertheless, I heard that chrome apps now supports C/C++ code, so maybe some crazy guys manage to port node.js to a chrome app, or do similar things).

The socket API of chrome is probably your eldorado.. But it is not flexible and convenient like dgram is. If you'are interested, I started writing something that tries to put a dgram-like API on top of chrome socket: https://github.com/alexstrat/chrome-udp-nodejs-socket but that's still experimental.

If you are building a desktop application (like you could do with kivy) but you'd prefer do it in node.js, you should have a look to http://appjs.com/

— Reply to this email directly or view it on GitHubhttps://github.com/alexstrat/simudp/issues/1#issuecomment-26377306 .

vanous commented 10 years ago

Hi,

i have tested all the bits of technology i need for my pet project, i seem to have it all prof of concept running and am back to simudp :)

Packets are not running through the proxy, is there something i am still missing? Please see this log below. this is from the server node.js. Do i need to do more at the side of the proxy? Please see pastebin snipets of code below, both are for node.js (i will run it in a browser later, when it's all working OK).

thank you

Petr

vanous@tc-vanek:~/bin/projects/node/anet/test$ node server.js
   info  - socket.io started
   debug - client authorized
   info  - handshake authorized GdejaHD3Re3aVoOAWmc6
   debug - setting request GET /socket.io/1/websocket/GdejaHD3Re3aVoOAWmc6
   debug - set heartbeat interval for client GdejaHD3Re3aVoOAWmc6
   debug - client authorized for
   debug - websocket writing 1::
   debug - client authorized for /simudp
   debug - websocket writing 1::/simudp
*   debug - websocket writing 5::/simudp:{"name":"error","args":["no port
available on server"]}*
   info  - booting client
   debug - websocket writing 0::/simudp
   info  - transport end (socket end)
   debug - set close timeout for client GdejaHD3Re3aVoOAWmc6
   debug - cleared close timeout for client GdejaHD3Re3aVoOAWmc6
   debug - cleared heartbeat interval for client GdejaHD3Re3aVoOAWmc6
   debug - discarding transport
   debug - client authorized
   info  - handshake authorized fsOLCS6kBv6ricqtWmc7
   debug - setting request GET /socket.io/1/websocket/fsOLCS6kBv6ricqtWmc7
   debug - set heartbeat interval for client fsOLCS6kBv6ricqtWmc7
   debug - client authorized for
   debug - websocket writing 1::
   debug - client authorized for /simudp
   debug - websocket writing 1::/simudp
   debug - emitting heartbeat for client fsOLCS6kBv6ricqtWmc7
   debug - websocket writing 2::
   debug - set heartbeat timeout for client fsOLCS6kBv6ricqtWmc7
   debug - got heartbeat packet
   debug - cleared heartbeat timeout for client fsOLCS6kBv6ricqtWmc7
   debug - set heartbeat interval for client fsOLCS6kBv6ricqtWmc7

http://pastebin.com/9bMC1NyD

http://pastebin.com/JTZwwqnQ

On Wed, Oct 16, 2013 at 11:38 PM, Petr Vanek petr@linuks.cz wrote:

Hi,

well, just for your interest... i tried to use the chrome.socket API. i can send arbitrary UDP packets from browser extension now but UDP broadcasts do not work i need them as my discovery process depends on it). I think your chrome-udp-nodejs-socket project will face similar issue... i presume that broadcast flag needs to be set to the system networking stack and although chromium seems to have this in it's code, the api is missing such an option...

Petr

On Wed, Oct 16, 2013 at 12:15 AM, Alexandre Lacheze < notifications@github.com> wrote:

Ah okay, I started to guess that doing a standalone app was your original intent !

As you concluded, simudp is not the solution since, as far as I know, there is no way to package a node.js server in chrome app and to make it run. (nevertheless, I heard that chrome apps now supports C/C++ code, so maybe some crazy guys manage to port node.js to a chrome app, or do similar things).

The socket API of chrome is probably your eldorado.. But it is not flexible and convenient like dgram is. If you'are interested, I started writing something that tries to put a dgram-like API on top of chrome socket: https://github.com/alexstrat/chrome-udp-nodejs-socket but that's still experimental.

If you are building a desktop application (like you could do with kivy) but you'd prefer do it in node.js, you should have a look to http://appjs.com/

— Reply to this email directly or view it on GitHubhttps://github.com/alexstrat/simudp/issues/1#issuecomment-26377306 .

alexstrat commented 10 years ago

Sorry I did not have time to test your code on my side yet. However, here are the things I find weird:

and btw, you should use https://gist.github.com/ instead of pastebin: it allows line-comments, syntax higlighting, forks..

vanous commented 10 years ago

Hi, hard time catching up too. The issue was that i didn't know that i am supposed to point my browser at the newly created http server, i was trying to open up the html page and presumed, that the http layer is there for the proxy purposes. Once i figured this out, all was simple. Perhaps it would't be bad idea to add to the readme?

On Mon, Oct 28, 2013 at 12:24 AM, Alexandre Lacheze < notifications@github.com> wrote:

Sorry I did not have time to test your code on my side yet. However, here are the things I find weird:

  • in logs you got :{"name":"error","args":["no port available on server"]}*. Are you sure you can bind a socket on 192.168.3.25:6454 ? If you are not sure, just try to run your client code with bare dgrammodule. Moreover, this log is in fact an error message of your socket: if you want to see them normally do client.on('error', function(err) {console.log(err};).
  • I've never tried to bind on an other interface than my localhost ( client.bind(port)). Are you you know what you do with that binding ?
  • I see you are using broadcast things, but as already said, I've never implemented in simudp the broadcast part of dgram. If you plan to use broadcast, you should probably start by trying to implement the missing part of simudp. You propose a pull request: I'll review it !

— Reply to this email directly or view it on GitHubhttps://github.com/alexstrat/simudp/issues/1#issuecomment-27182422 .