I use it to keep my secure RPC off the network entirely and give permissions to access the RPC. If this can be duplicated (the permissions, I can firewally the box) it sounds fine. If this can be moved to userland this is fine, but I suspect some people will end up using Windows Pipes for similar purposes as Unix Domain Sockets.
On Wed, Aug 24, 2011 at 11:22, Jeroen Janssen <jeroen.jans...@gmail.com> wrote: > just to clarify.. does this mean that from the > http://nodejs.org/docs/v0.4.11/api/dgram.html#dgram.createSocket only > 'unix_dgram' will be removed? > (i.e. the rest: udp4 and udp6 will keep on existing?)
Yes, that's correct. unix_dgram is out, udp4 and udp6 are in. Broadcast and multicast support is missing at the moment but we'll add those.
On Wed, Aug 24, 2011 at 09:28, Isaac Schlueter <i...@izs.me> wrote: > Cluster is fairly popular. Breaking it should at least have really > good justification, or better yet, a clear workaround.
Use UDP sockets or streaming UNIX sockets.
I've taken a peek at cluster's source. The sockets are used for a JSON-RPC like protocol. It doesn't seem like they need unix_dgram as such (please correct me if I'm wrong).
On Wed, Aug 24, 2011 at 8:47 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote: > On Wed, Aug 24, 2011 at 09:28, Isaac Schlueter <i...@izs.me> wrote: > > Cluster is fairly popular. Breaking it should at least have really > > good justification, or better yet, a clear workaround.
> Use UDP sockets or streaming UNIX sockets.
> I've taken a peek at cluster's source. The sockets are used for a > JSON-RPC like protocol. It doesn't seem like they need unix_dgram as > such (please correct me if I'm wrong).
On Wed, Aug 24, 2011 at 16:18, Matt <hel...@gmail.com> wrote: > Can you answer hij1nx's question? What's the motivation for removing it?
Sure: hard to get right cross-platform and almost no one uses it. We have limited developer resources so spending a man week on something that has only a handful of users didn't seem worthwhile, there are bigger fish to fry.
That seems fair enough... But then is there a reason the release can't get pushed back a man week to get it working? Seems like it might not be the easiest thing to add in as a userland option, since you'd have to hook into the event loop directly, rather than the eio_custom() stuff...
Or alternatively just make it non-Windows only in 6.0 and if someone wants it for windows ask for patches.
On Wed, Aug 24, 2011 at 10:27 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote: > On Wed, Aug 24, 2011 at 16:18, Matt <hel...@gmail.com> wrote: > > Can you answer hij1nx's question? What's the motivation for removing it?
> Sure: hard to get right cross-platform and almost no one uses it. We > have limited developer resources so spending a man week on something > that has only a handful of users didn't seem worthwhile, there are > bigger fish to fry.
Pretty certain a dependency like Cluster means that quite a few more than "almost no one" use it. In addition to what Issac said, there are 6 packages that depend on cluster (within NPM alone -> http://search.npmjs.org/#/cluster), Haraka and Calipso being somewhat popular as well.
IMO, If it isn't broken out to user land then push the release a week and fix it.
On Wed, Aug 24, 2011 at 10:27 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote: > On Wed, Aug 24, 2011 at 16:18, Matt <hel...@gmail.com> wrote: > > Can you answer hij1nx's question? What's the motivation for removing it?
> Sure: hard to get right cross-platform and almost no one uses it. We > have limited developer resources so spending a man week on something > that has only a handful of users didn't seem worthwhile, there are > bigger fish to fry.
> On Wed, Aug 24, 2011 at 16:18, Matt <hel...@gmail.com> wrote: >> Can you answer hij1nx's question? What's the motivation for removing it?
> Sure: hard to get right cross-platform and almost no one uses it. We > have limited developer resources so spending a man week on something > that has only a handful of users didn't seem worthwhile, there are > bigger fish to fry.
Everyone should relax a little and understand what is being asked.
- Unix domain sockets are a very important feature and we will continue to support it forever
- UDP is a very important feature and we will continue to support it forever
What we're removing support for is socket(AF_UNIX, SOCK_DGRAM, 0). It is almost certain that no one is using this. We want to remove it because the equivalent does not exist on windows and it's a strange functionality.
Oops - Cluster is actually using this. TJ will need to frame his protocol for transport over unix stream sockets. This is fairly minor.
Unrelated to the AF_UNIX SOCK_DGRAM discussion, we're likely to be changing our API for sharing file descriptors across processes which will probably require cluster (and similar modules) to be rewritten totally. A discussion about that can be moved to the node-dev list.
+1 to removing it if it helps move to 0.6 more quickly.
My feeling is that this is a major horizon in node development. Once true Windows compatibility is achieved there will be a huge influx of new users as well as new and varied use cases. Lots of things will probably get a second look in terms of what "core" is. The sooner we reach this milestone, the sooner we can start sorting things out.
As for Cluster, those guys are pretty smart and I'm sure they don't *need* unix dgrams to achieve what they need to. They'll probably just use some other socket type and no one will be the wiser.
With that said, I think what people would like to hear is that Ryan and Joyent have a strategy for evolving node in a sane fashion across Windows and *nix systems. In general I think people would like to hear that node will still take advantage of nice features that are well supported on unix, even if they can't be properly reproduced on Windows.
> The node core team wants to drop node's support for unix datagram > sockets in v0.6. We think nobody is using it anyway. > But we might be wrong. If you *are* using this functionality, speak up > now or forever hold your peace.
On Wed, 24 Aug 2011 05:30:37 -0700 (PDT), Bradley Meck wrote: > I use it to keep my secure RPC off the network entirely and give > permissions to access the RPC. If this can be duplicated (the > permissions, I can firewally the box) it sounds fine. If this can be > moved to userland this is fine, but I suspect some people will end up > using Windows Pipes for similar purposes as Unix Domain Sockets.
Why not just loopback/socket file? Usually they don't even go down the network stack.
On Wed, Aug 24, 2011 at 8:47 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> I've taken a peek at cluster's source. The sockets are used for a > JSON-RPC like protocol. It doesn't seem like they need unix_dgram as > such (please correct me if I'm wrong).
Using unix streams would significantly complicate the code in cluster's master.js as it would need to maintain an individual socket connection / session per child node process. Using dgrams you don't suffer from all of that connection maintenance overhead if you don't need it. I have an project that does the same thing for communicating between node & a server written in Erlang for message passing on the same box.
On Wed, Aug 24, 2011 at 4:12 AM, David Goehrig <d...@nexttolast.com> wrote: > I've been using them for mDNS discovery. If you drop support I guess I'll have to fork.
You're using unix datagram sockets for mDNS discovery?
We don't specify the language, we don't build the VM, and we don't go too far up the stack building a huge stdlib.
0.6 is adding another dimension, node.js doesn't do Unix (or Windows) specific APIs. Those go in to userland modules now.
It makes sense to me. If we want Windows support to be sustainable node should not make an effort to support features that don't appear in both Unix and Windows.
Of course, userland modules are free to provide APIs for all kinds of OS specific features.
-Mikeal
On Aug 24, 2011, at August 24, 20119:48 AM, Ryan Dahl wrote:
> Everyone should relax a little and understand what is being asked.
> - Unix domain sockets are a very important feature and we will > continue to support it forever
> - UDP is a very important feature and we will continue to support it forever
> What we're removing support for is socket(AF_UNIX, SOCK_DGRAM, 0). It > is almost certain that no one is using this. We want to remove it > because the equivalent does not exist on windows and it's a strange > functionality.
I understand what's being asked. My argument though is that I don't see a way currently to implement this in userland unless you provide a way to say "Give me all events on this FD" in your C++ API. I could be missing that though - the C++ side of things is an area that needs documented (not a criticism per-se, just something to go on the list).
If it's implementable in userland with the current API (i.e. if I'm wrong about the above) then I say scrap it. People who want unix-only features can write those as external libraries.
On Wed, Aug 24, 2011 at 12:48 PM, Ryan Dahl <r...@tinyclouds.org> wrote: > Everyone should relax a little and understand what is being asked.
> - Unix domain sockets are a very important feature and we will > continue to support it forever
> - UDP is a very important feature and we will continue to support it > forever
> What we're removing support for is socket(AF_UNIX, SOCK_DGRAM, 0). It > is almost certain that no one is using this. We want to remove it > because the equivalent does not exist on windows and it's a strange > functionality.
> The node core team wants to drop node's support for unix datagram
> sockets in v0.6. We think nobody is using it anyway.
> But we might be wrong. If you *are* using this functionality, speak up
> now or forever hold your peace.
> its bad idea node.js as i understood was planed to be used create
network apps.
This is true. On the other hand, we ain't Twisted either (which, for example, has irc-specific code in its core). It's okay for functionality to live entirely in userspace, really! ;)
Matt said:
> My argument though is that I don't see a way currently to implement this in userland unless you provide a way to say "Give me all events on this FD" in your C++ API.
This is a good point. How hard would it be to implement unix datagram sockets in userspace? Is it doable?
Matt said:
> If it's implementable in userland with the current API (i.e. if I'm wrong about the above) then I say scrap it. People who want unix-only features can write those as external libraries.
I think "scrap it" is dangerous here, since I think the node core devs should be open to the idea of moving such code into external libraries instead of just killing it.
Speaking of: Would anybody here that currently uses unix datagram sockets be interested in maintaining such a project? I mean, if nobody uses them then the answer is obviously "no," but it sounds like some people might be.
On Wed, Aug 24, 2011 at 12:19 PM, Shimon Doodkin <helpmep...@gmail.com> wrote: > its bad idea node.js as i understood was planed to be used create > network apps.
> On Aug 24, 4:23 am, Bert Belder <bertbel...@gmail.com> wrote: >> Hey all,
>> The node core team wants to drop node's support for unix datagram >> sockets in v0.6. We think nobody is using it anyway. >> But we might be wrong. If you *are* using this functionality, speak up >> now or forever hold your peace.
> On Wed, Aug 24, 2011 at 11:22, Jeroen Janssen<jeroen.jans...@gmail.com> wrote: >> just to clarify.. does this mean that from the >> http://nodejs.org/docs/v0.4.11/api/dgram.html#dgram.createSocket only >> 'unix_dgram' will be removed? >> (i.e. the rest: udp4 and udp6 will keep on existing?) > Yes, that's correct. unix_dgram is out, udp4 and udp6 are in. > Broadcast and multicast support is missing at the moment but we'll add > those.
My only requirement/request is to be able to implement mDNS advertisement and discovery without having to resort to a C++ addon. If I understand correctly, the dgram unix stuff is unrelated, but we are still missing the broadcast and multicast parts needed.
>> Yes, that's correct. unix_dgram is out, udp4 and udp6 are in. >> Broadcast and multicast support is missing at the moment but we'll add >> those.
>> My only requirement/request is to be able to implement mDNS advertisement > and discovery without having to resort to a C++ addon. If I understand > correctly, the dgram unix stuff is unrelated, but we are still missing the > broadcast and multicast parts needed.
Yes it's unrelated, but I think everything you need for mDNS should be there. You'll have to construct your own DNS packets though.
On Aug 24, 9:37 pm, Tim Caswell <t...@creationix.com> wrote:
> My only requirement/request is to be able to implement mDNS
> advertisement and discovery without having to resort to a C++ addon. If
> I understand correctly, the dgram unix stuff is unrelated, but we are
> still missing the broadcast and multicast parts needed.
Yes, the dgram unix stuff is unrelated.
Yes, broadcast/multicast is still missing, but this will be re-added
before 0.6.
On Wed, Aug 24, 2011 at 3:35 PM, Joshua Holbrook <josh.holbr...@gmail.com>wrote:
> Matt said: > > My argument though is that I don't see a way currently to implement this > in userland unless you provide a way to say "Give me all events on this FD" > in your C++ API.
> This is a good point. How hard would it be to implement unix datagram > sockets in userspace? Is it doable?
Probably, but the "how" is likely to change with UV. Right now you could probably (I presume) create your own ev_io in C++ and ev_init() that.
Matt said:
> > If it's implementable in userland with the current API (i.e. if I'm wrong > about the above) then I say scrap it. People who want unix-only features can > write those as external libraries.
> I think "scrap it" is dangerous here, since I think the node core devs > should be open to the idea of moving such code into external libraries > instead of just killing it.
Well that's what I mean by scrap it. Very much like my node-fs-ext library.
> > I am not sure if it uses UDP, but Bonjour/ZeroConf also uses a
> > multicast mechanism in order to work.
> > On Aug 24, 3:58 am, Matt Stevens <m...@alloysoft.com> wrote:
> > > On Aug 23, 7:34 pm, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> > > > Another thing is that multicast support for dgram sockets is - at
> > > > least for now - disabled. I'd like to know how many people actually
> > > > use that and for what (the what is optional, just genuinely curious).
> > > I tinkered with a UPnP/DLNA media server, the ability to join a UDP
> > > multicast group is needed there to advertise the services. Based on
> > > this thread it sounds like others are interested in the same thing:
On Wed, Aug 24, 2011 at 21:15, tjholowaychuk <tjholoway...@gmail.com> wrote: > Cluster doesn't need to use local sockets, I can change that, I'm fine > with the removal
