Repository navigation
dependency on nginx #7
Description
Hi, I was wondering if the dependency on nginx is necessary? It looks like you are using it for a queue type. Would it be possible to remove this so I can use it with node by itself?
./handle_wrap.h:#include "ngx-queue.h"
./handle_wrap.h: ngx_queue_t handle_wrap_queue_;
Activity
formula1 commentedon May 19, 2015
You know, you probably have a point (I don't know the specifics). But it's been two years since the devs last commit : / I hope he responds. But I suspect any further changes would be by a fork, though I would argue this functionality should be in core
VanCoding commentedon May 19, 2015
Wow, there are still people interested in this? o.O
What are you using this for? Or, what do you think this module can be useful for?
When I created this module, I thought it would be a good idea to use this as a frontend that passes/routes incoming http requests's sockets to processes that are responsiple for the route. But it led to much more problems than I have expected, so I decided to not do it anymore and proxy instead. One problem, for example, was the fact, that it was impossible to pass encrypted sockets, or that one socket could receive multiple requests with different routes (which could mean that they should have been routed to another process) and so on. So I'm quite interested in a good usecase for node-ancillary.
Honestly, it's been a while and I don't even remember adding the nginx dependency or what it's used for. It could have happened by accident.
Does the code even work with current node versions? I can imagine that there were a lot of api changes that could have broken compatibility.
What's also worth checking is, like @formula1 said, if it's not already possible to do without node-ancillary and just with node.js. Libuv has features for passing handles between processes. I've tried to use them back when I've written this module, but it was very buggy and didn't work, so I decided to do it in c++ instead of using the javascript bindings.
formula1 commentedon May 19, 2015
Thanks for responding ^__^
I was helping with a project a couple months ago. There each of the apps ran in child processes that connected to a main server which was connected to the ui. I didn't end passing the sockets since I started helping a couple other projects (one I did end up passing the sockets to the correct location, though seperate processes didn't matter). By allowing processes to be able to be spun up by the command line
sudotype applications, where the master server should not be run with sudo, since it will pass on its credentials to all children. However some applications will need sudo access, which should be run seperately but still hook into the ui. (though this may be circumvented with a prompt that writes to the stdin)The important part about passing sockets to child/peer processes is simple of course. Only applications that actually care about a socket get the socket. If that application goes into an infinite loop, it doesn't block the whole system. If the application crashes, we can remove and/or restart without getting into npm cache/vm craziness.
Proxies work, though now it may be necessary to have a larger cluster of proxies since all requests/responses would have to go through them : / Also you would need to find out available ports and in the case where you have alot of processes running at once, things may start to get messy.
That being said, I still believe this functionality (though somewhat fringe to my specific use case) still ought to be in core. In my not so humble opinion, Node Processes should be able to have "special" conversions with each other, up to and including passing servers or sockets. For me I have been just doing work so I haven't been really focused on this particular module. Though I do pay attention to it because its great.
immjs commentedon Dec 8, 2024
After briefly looking, I believe
src/handle_wrap.hwas induced by NodeJS. (something something "replicate the net module")This also causes issue #8
(And sorry for the necro-bump)