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

11–20 of 36 posts

Re: Two pieces of code someone really ought to write

#11

Post by jrockway »

nostrademons wrote: post #10
jrockway wrote: post #7

The first issue is a programming language problem, not an OS problem. His language of choice exposes the direct low-level API, which is not usually what application-level programmers want. A few library functions, and the problem is solved without FUSE or a performance impact. And it's still portable to everywhere.

But then you have to implement the solution in every language, while with FUSE, you implement it once and each language runtime instantly has access to it.

Knock yourself out, then. Every language I use (including C) already has a sugary socket API, though.

Re: Two pieces of code someone really ought to write

#13

Post by joelhaasnoot »

glhaynes wrote: post #5
joelhaasnoot wrote: post #2

Regarding your first point... You forget one thing: you open a file and get a file descriptor. If you open a socket (though it takes 3 calls), it also returns a file descriptor. Sockets can then be written to and read from just like files. Won't even get started then about the fact that sockets allow you to do just about any type of networking, and are very abstract by purpose, to allow a variety of uses.

Sounds like opening a socket could be reduced to one call, so why not fopen()? Seems like it'd be an easy thing to get into a kernel, any reason not to?

The question is if fopen() would then still work with embedded or archaic architectures. Examples such as radio links on tiny 16-bit hardware come to mind.

Re: Two pieces of code someone really ought to write

#15

Post by pmorici »

kd0amg wrote: post #12

My network programming background is a bit small. Could someone explain for me the difference between what OP calls for with sockets and a tun/tap device?

A tun/tap device is a way to write a user space network driver for a piece of hardware to make it look like a network device to the OS. ie: you could make a serial serial cable look like a network device.

What this blog is asking for is a different way to access network resources so instead of calling a function like socket(some_ip, some_port, SOME_PROTOCOL); (which is a gross over simplification for the typical way it is done) he wants to be able to say open("/net/some_ip/protocol/some_port", "rw");

Re: Two pieces of code someone really ought to write

#16

Post by SageRaven »

_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…

FreeBSD has this (mount_portalfs, whose man page references the paper you link to), though I've only messed with it sparingly out of curiosity. Not sure how stable it is, but I thought it was really cool when I stumbled upon it one day.

Re: Two pieces of code someone really ought to write

#17

Post by DougWebb »

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 specific format (host/ip) and others are arbitrary. Some have to be directories, some have to be files, and some are neither. None of this is very filesystem-like. I think the current design is right: opening sockets is kind of special, but you get a filehandle that is very much like an ordinary filehandle.

Re: Two pieces of code someone really ought to write

#18

Post by dododo »

moe wrote: post #14

FWIW, Bash has this built in; cat It's unfortunately disabled in the bash that ships with debian, but should work pretty much everywhere else.

awk has something similar too:

  The following special filenames may be used with the |&
  co-process operator for creating TCP/IP network connections.

  /inet/tcp/lport/rhost/rport  File for TCP/IP connection 
  on local port lport to remote host rhost on remote port 
  rport.  Use a port of 0 to have the system pick a port.

Re: Two pieces of code someone really ought to write

#20

Post by dedward »

"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 machine (Oh? You think that's not reasonable? Can you say "multi-core architecture"?) that can become a serious administrative (to say nothing of security) nightmare."

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

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. Whether you are opening unix domain sockets or assigning ports, you still have to track and configure everything - and that can still be automated. While it would be a neat feature - it doesn't seem like a terribly necessary one.

Yes, it would be cool if apache could forward things to a local unix domain socket. Agreed there.

But there's no security nightmare unless you create one - in the instance you describe you bind applications to loopback interfaces, either on ports or creating more loopback interfaces. Designing the applications to use TCP sockets rather than unix domain sockets also leaves you with more flexibility when it comes to design decisions later on - you don't have to leave them on the same machine.

ALso - one wouldn't generally use apache for this - one would use something else as a front end these days that's better suited to forwarding requests and dealing with timeouts, resources, etc.

Post reply on HN