Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two pieces of code someone really ought to write

rondam.blogspot.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Two pieces of code someone really ought to write

#21

Post by lisper »

DougWebb wrote: post #17

If you allow this: open("/fuse/sockets/www.whatever.com/tcp/80", "r+") Then what do you do with these? /fuse/sockets/www.whatever.com/tcp /fuse/sockets/www.whatever.com /fuse/sockets They and other variations would each need different semantics, some allowing rw, some ro, some wo, and some not being allowed at all. Some path segments would not allow arbitrary names (tcp/udp, port number) while others require a specif…

> Then what do you do with these?

The same things you do with any other incomplete path name. I don't see why this is an issue at all.

Re: Two pieces of code someone really ought to write

#22

Post by iuytrfghj »

brutimus wrote: post #6

You can sorta get what he's asking for with a bash feature. http://tldp.org/LDP/abs/html/devref1.html#DEVTCP

Yes but thats a hack built into bash

The point of unix is to do everything in the file system then anything that can open a file can do everything

Re: Two pieces of code someone really ought to write

#23

Post by endlessvoid94 »

DougWebb wrote: post #17

If you allow this: open("/fuse/sockets/www.whatever.com/tcp/80", "r+") Then what do you do with these? /fuse/sockets/www.whatever.com/tcp /fuse/sockets/www.whatever.com /fuse/sockets They and other variations would each need different semantics, some allowing rw, some ro, some wo, and some not being allowed at all. Some path segments would not allow arbitrary names (tcp/udp, port number) while others require a specif…

Treat them as empty, read only directories?

Re: Two pieces of code someone really ought to write

#24

Post by lisper »

dedward wrote: post #20

"But now suppose that I have a single machine with a single IP address hosting multiple virtual servers, and I want to replicate this setup for each virtual server, i.e. I want each virtual server to have its own instantiation of the custom server application. Now I have to manually assign each instantiation of the app to a separate TCP port number. If I have hundreds or thousands of virtual servers on the same machi…

> Not quite sure I'm interpreting you correctly here - but woudln't you be using localhost for this and/or using loopback interfaces?

Sure. But you still have to assign a port number. And you still have to make a round trip through the network stack. It's also a potential security hole if you're not careful to configure the server apps to only listen on the loopback interface.

> Also - if you were designing an application that had to scale out to that many cores, you'd be dealing with things at a system level and using sockets anyway.

Why? Running N servers on N machines is completely straightforward. Why should it not be just as straightforward to run N servers on one machine with N cores?

> you still have to track and configure everything - and that can still be automated

Of course it can be automated, but automating the assignment of virtual servers to TCP/IP ports is not straightforward. You have to coordinate the port assignment on both the client and the server side. You have potential synchronization issues if one virtual server goes down and another comes up and wants to use the same port as the one that went down. Port numbers are a scarce resource. The file system namespace is essentially infinite. Why make things harder than they need to be?

Re: Two pieces of code someone really ought to write

#25

Post by leif »

_delirium wrote: post #3

There are a few attempts to make sockets look like a Unix filesystem, but none seem to have caught on, perhaps partly because sockets are pretty portable, while fs-like interfaces, unless one gets widespread support to the extent of being a POSIX-like "assumed to be on all UNIXes", are inevitably tied to a particular OS flavor. I believe Plan9 was the first to have support for the idea, though, and NetBSD has had it…

socat is a little closer to what you really want than netcat: http://www.dest-unreach.org/socat/

Re: Two pieces of code someone really ought to write

#26

Post by _cbsz »

lisper wrote: post #21
DougWebb wrote: post #17

If you allow this: open("/fuse/sockets/www.whatever.com/tcp/80", "r+") Then what do you do with these? /fuse/sockets/www.whatever.com/tcp /fuse/sockets/www.whatever.com /fuse/sockets They and other variations would each need different semantics, some allowing rw, some ro, some wo, and some not being allowed at all. Some path segments would not allow arbitrary names (tcp/udp, port number) while others require a specif…

> Then what do you do with these? The same things you do with any other incomplete path name. I don't see why this is an issue at all.

There's no such thing as an "incomplete path name", those have to be directories.

Re: Two pieces of code someone really ought to write

#27

Post by sjs »

lisper wrote: post #9
_delirium wrote: post #3

There are a few attempts to make sockets look like a Unix filesystem, but none seem to have caught on, perhaps partly because sockets are pretty portable, while fs-like interfaces, unless one gets widespread support to the extent of being a POSIX-like "assumed to be on all UNIXes", are inevitably tied to a particular OS flavor. I believe Plan9 was the first to have support for the idea, though, and NetBSD has had it…

> while fs-like interfaces, unless one gets widespread support to the extent of being a POSIX-like "assumed to be on all UNIXes" FUSE runs on pretty everything, doesn't it?

It runs on most popular Unix-ish systems.

Re: Two pieces of code someone really ought to write

#29

Post by nl »

NO NO NO!!! For the sake of all that is holy don't do it!!!!

Or rather, read & understand the fallacies of network programming: http://www.jezuk.co.uk/cgi-bin/view/jez?id=2650 before you do it.

The failure mode of networks is quite different to that of files, and the programming model reflects that.

Re: Two pieces of code someone really ought to write

#30

Post by lisper »

_cbsz wrote: post #26
lisper wrote: post #21

Earlier quoted context omitted.

> Then what do you do with these? The same things you do with any other incomplete path name. I don't see why this is an issue at all.

There's no such thing as an "incomplete path name", those have to be directories.

So treat them as directories (or more specifically, as mount points). I still don't see the problem.
Post reply on HN