Windows support

[Rush]

I am planning to build my future project around the concept of your project. Are you planning to implement Windows support? (probably would requie some dark magic kung fu :) )

[VanCoding]

I tought about it, but had to less time to do it because of studying. I have my final exam in 1 week and will then have all time in the world :D

I think I will try to do it anytime after that.

[Rush]

Oh thanks a lot! In that case nothing is stopping me from utilizing your awesome library. :) I look forward to seeing your improvements and good luck with the exams!

[VanCoding]

Ok, nice! But please keep in mind that is a very young, untested library that I'm not sure if it will work under very heavy loads. I've used it in a few of my projects and does a really god job, but they aren't open to the public tough.
I just recommend you to test if the library works for your project and probably prepare to use an alternative way if there are problems.

[Rush]

Well actually I start my processes with child_process' fork, so the stated functionality "This module for node.js allows you to send socket objects to other node.js processes that are completely unrelated." is a bit too much for my needs but then I have not found any other solution that would allow to cleanly share only selected sockets with my child processes. (Cluster allows to share it all, and then closing the unneeded sockets is ugly - also Cluster is much too much). But sure, I will play with your code and I have been warned. ;)

[VanCoding]

If you start your other process using fork, then there IS another possibility that I would recommend you. Forked childprocesses have a built-in message channel to communicate with the host process. This channel is not only to JSON data. The cp.send function accepts a second argument on that you can pass a socket handle. the "message" event then gets this handle and you can use it. This works for server handles as well as socket handles. It works in both ways.

Maybe you should checkout this. It would suit your needs best.

http://nodejs.org/api/child_process.html#child_process_child_send_message_sendhandle

[Rush]

Hmm, I wish the doc was more clear on this issue. ;) I will try this out, thank you!

[Rush]

I had problems with the fork and sendHandle but it seems that the Git version of node is much more ahead on this. https://github.com/joyent/node/blob/master/doc/api/child_process.markdown - I may be forced to use Node from Git until they make a new release. Maybe there are changes that would help your case as well.

[VanCoding]

Thanks @RushPL, I'm now using the functionality of node.js to do exactly the same. I still had to use native code to fix a bug of libuv. This fix allowed me to send handles over pipes to other processes.

Since I now rely on the code of node.js itself, it's only a matter of time until this library becomes cross-platform.

[avnerz]

Hello - thanks for the useful library (hope your studies are going well!)

Question for you: I am used node-ancillary and when I send out large amounts of data I experience a noticeable (order of whole seconds) slowdown (> 100K). When the data size reaches 300K the data never gets sent out. Looking through the send function in ancillary.js, is it possible in your opinion that the slowdown is caused by the string manipulations in JavaScript? I noticed the 1 second timeout in the send function - is it possible in your opinion that this is what causes the data to never get sent?

The reason I am asking, is because I want to understand if bugs in the library are fixed, if the basic approach is robust enough o power a public server.

Thanks again!

[VanCoding]

@avnerz Thanks for your interest.
Actually, I don't know how well node-ancillary performs on heavy load.
I also don't know how to reliably test such things.

I use this library to run multiple apps/pages on the same port, while each app runs in its own process and listens for requests from node-ancillary. This actually works pretty well for my not very popular sites (mostly only visited by myself :D) as you, for example, can see at this site: https://eventlighting.ch. It runs 100% over node-ancillary.

BUT: I'm using a newer version of node-ancillary, which is very different from the version here on github. I did not have the time yet to publish it, since I also would need to change the docs.

The version on github has one big problem: It's not possible to reuse a connection for another HTTP request. So, your pages will load relatively slow, since the browser needs to make a new connection for each request.

The only solution I found was using node-spdy which allows HTTP multiplexing. For each request stream, I then created a unix-socket to the process itself, so that I get a handle I can sent to other processes.

So, there is still one socket per request, but only one connection to the browser.

It works pretty well, but I had to implement parts of the HTTP protocol myself to get it working.

If you want, I can push the newest version of ancillary, so you can try it again.
I'd really like to help you with testing it!

[avnerz]

Hi Patrick,Thanks so much for the informative response!I'm using node-ancillary with a websocket implementation. I have a browser connect to a server process that then delegates socket connections to sessions that run in separate processes on the server. The websocket connection (based on the example on the node-ancillary site) gets forwarded to the session process, and then communication continues. The session process sends messages down to the browser via the socket that got forwarded to it by the server. When it sends larger messages, things become very slow, and when the message is a bit larger it stops getting delivered. The problem can be reproduced by sending a 300K message down to the browser over the socket.Since this relies on websockets, there is only one HTTP request per session, so the multiple request problem you mentioned is not something I'm experiencing right now.If I am able to solve this problem, I will let you know what I discovered!Blessings,Avner.

-------- Original Message --------
Subject: Re: [node-ancillary] Windows support (#1)
From: Patrik Stutz notifications@github.com
Date: Wed, February 13, 2013 9:07 am
To: VanCoding/node-ancillary node-ancillary@noreply.github.com
Cc: Avner Zangvil avner@newdayweb.net@avnerz Thanks for your interest. Actually, I don't know how well node-ancillary performs on heavy load. I also don't know how to reliably test such things. I use this library to run multiple apps/pages on the same port, while each app runs in its own process and listens for requests from node-ancillary. This actually works pretty well for my not very popular sites (mostly only visited by myself :D) as you, for example, can see at this site: https://eventlighting.ch. It runs 100% over node-ancillary. BUT: I'm using a newer version of node-ancillary, which is very different from the version here on github. I did not have the time yet to publish it, since I also would need to change the docs. The version on github has one big problem: It's not possible to reuse a connection for another HTTP request. So, your pages will load relatively slow, since the browser needs to make a new connection for each request. The only solution I found was using node-spdy which allows HTTP multiplexing. For each request stream, I then created a unix-socket to the process itself, so that I get a handle I can sent to other processes. So, there is still one socket per request, but only one connection to the browser. It works pretty well, but I had to implement parts of the HTTP protocol myself to get it working. If you want, I can push the newest version of ancillary, so you can try it again. I'd really like to help you with testing it! — Reply to this email directly or view it on GitHub.

[VanCoding]

@avnerz I've now updated node-ancillary to my local state. It's still possible to send WebSockets, but I don't have an example or documentation yet. I'll add it later.

But there are 2 different cases when sending WebSockets:

Case A: the connection is not yet established.
In this case, you're able to route the upgrade request itself, you can just send the upgrade reqest.

Case B: the connection is established (the response headers are already sent)
In this case, you must send the object gotten from c.upgradeReq and the receiver must prevent sending the response headers again.