OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 9:21 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 1:42 am 
Offline
Member
Member
User avatar

Joined: Fri May 14, 2010 3:46 pm
Posts: 62
Location: New York, NY
The unix philosophy of "treat everything as a file" doesnt truely apply to sockets, however I'm under the impression that plan 9 has managed to implement a socketFS.
Is there any disadvantages to doing so? Also, how would I begin to do somthing like it? I'm not asking for a tutorial here, more like a working explanation I can wrap my head around.

I understand the concept of special files and the like, but web sockets seem a bit too... Well, far away from a file.

_________________
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."
Image


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 2:19 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Primis wrote:
The unix philosophy of "treat everything as a file" doesn't truly apply to socket .... I understand the concept of special files and the like, but web sockets seem a bit too... Well, far away from a file.

Could you perhaps expand on those statements?


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 3:14 am 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 1074
The reason that you would "treat" everything like "one" thing is that something will need to "use" that thing in the future, and trying to pre-define every different type of thing would (literally) take forever. So, the easiest approach is to pre-define one thing, and then make everything act according to those pre-defined rules.

That "thing" that you define can be anything you want: a file, a pipe, a stream, an object, a widget. You just have to define what that thing is/can do, and then you have to figure out how to "force" all of the real world things into that one "thing".

If you do it right, then you only have to write your code once, and it will work for any situation.

Also, keep in mind that naming your stuff is simply for your benefit, and perhaps the benefit of your users. The machine could care less what you call it.

EDIT: Also, keep in mind that the Linux "file" paradigm is only used on the user facing end of the OS. Behind the "file" facade, you also have "modules", "drivers", "consoles", "devices", "processes", etc. So even Linux doesn't really stick to one definition of a "thing".

_________________
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 4:25 am 
Offline
Member
Member
User avatar

Joined: Wed Dec 01, 2010 3:41 am
Posts: 1761
Location: Hong Kong
The main operations on file include: open, close, read, write and seek (thanks alexfru). This pretty much covers everything in the world, or do they?

Then you have special cdrom that acts as file, but you need to support a function to eject the disc.
Then you have linear frame buffer that acts as a file, but you need a way to adjust video mode.
Then you have special sound card that acts a a file, but you need to provide device control function like volume and mechanism for injecting audio filters.

Then you want to have event-based notifications beside the basic read/write (e.g. use press the eject button).

All those extra control is not unified into the file concept (although you assign function in ioctl, it just doesn't make sense to eject disc on a sound card).


On Linux, the OS give up and the file concept works just like IPC. You then open up a data transfer file and a control file and do it yourself for everything other that a real file.


Last edited by bluemoon on Sun Jul 05, 2015 4:33 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 4:30 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
bluemoon wrote:
The main operations on file include: open, close, read, write. This pretty much covers everything in the world, or do they?


lseek?


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 5:09 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
alexfru wrote:
bluemoon wrote:
The main operations on file include: open, close, read, write. This pretty much covers everything in the world, or do they?


lseek?
I'd disagree with that one.

I guess it all depends upon what you call a "file" but to my mind you can only perform seek operations on a random-access file. (The same would be true for pipes.) The concept of a sequential file, which can only be read from start to end (although perhaps you can allow for forward-only seeks that ignore parts of the file), is a useful one. I agree with bluemoon's other operations, and sockets support all of them; hence my request for a clarification from the OP as to in which way the file designation is not appropriate for sockets.


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 5:16 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
iansjack wrote:
alexfru wrote:
bluemoon wrote:
The main operations on file include: open, close, read, write. This pretty much covers everything in the world, or do they?


lseek?
I'd disagree with that one.

I guess it all depends upon what you call a "file" but to my mind you can only perform seek operations on a random-access file. (The same would be true for pipes.) The concept of a sequential file, which can only be read from start to end (although perhaps you can allow for forward-only seeks that ignore parts of the file), is a useful one.


I didn't say it wasn't useful. But there are a lot of important file formats and software that need random access to files. You may argue that one could read the whole thing into RAM and do in-memory seeks, but that's not something always practical. So, I wouldn't discard lseek.


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 5:20 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
I'm not suggesting that you discard lseek as an operation on (random-access) files, just that it is not a necessary operation on any file.

The reason that I think sockets are validly considered as files is because that allows them to be redirected to STDIN and STDOUT.


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 5:22 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
iansjack wrote:
I'm not suggesting that you discard lseek as an operation on (random-access) files, just that it is not a necessary operation on any file.

The reason that I think sockets are validly considered as files is because that allows them to be redirected to STDIN and STDOUT.


No objection there.


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 5:52 am 
Offline
Member
Member
User avatar

Joined: Wed Dec 01, 2010 3:41 am
Posts: 1761
Location: Hong Kong
iansjack wrote:
I'm not suggesting that you discard lseek as an operation on (random-access) files, just that it is not a necessary operation on any file.
The reason that I think sockets are validly considered as files is because that allows them to be redirected to STDIN and STDOUT.


However, as in CDROM and sound card cases, sockets is more than file. You have connections, events, windowing, dynamics, and other consideration. It would be better to say socket is not exactly to design as a file, but it can inherent the basic file operations and manipulated like a file in part of its life cycle.


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 8:55 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Quote:
However, as in CDROM and sound card cases, sockets is more than file.
But surely it is true to say that any file is more than a (generic) file? For example, with a random-access file on a disk you can seek it, which you cannot necessarily do with a generic file. (I think this is where we came in.)


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 3:03 pm 
Offline
Member
Member
User avatar

Joined: Fri May 14, 2010 3:46 pm
Posts: 62
Location: New York, NY
To expand a little,
Plan 9 has a /net directory, and rather than use ioctls to open and close new sockets, you write to a special file called /net/tcp or /net/udp to create sockets.
Plan 9 literally has everything as a file. And unfortunately, the plan 9 website is down (http://plan9.bell-labs.com) and there isn't much other information on their implementation.

_________________
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."
Image


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Sun Jul 05, 2015 8:56 pm 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 1074
There have been several threads about different "file" systems, and how they try to "organize" things. I have a bit of a problem with "files" as a base object definition, especially when it comes to personal OS development.

As far as I can tell, the concept of "files" was an attempt to help users understand the concept of organizing data on a storage device by "emulating" a file cabinet, with file folders, and documents. But the concept doesn't hold up very well in the real world, where documents can be shared between people and applications, indexed in different ways.

As just one example, how many times have you run a music application that immediately wants to reorganize all of your music files into a specific folder structure? How about multiple users? What if two users want their music organized differently?

The file/folder paradigm doesn't hold up well to these types of requirements. If you are creating your own OS, why stick to "traditional" solutions to these problems. Try thinking outside the box before you decide to go down that path.

_________________
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Wed Jul 08, 2015 10:06 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
@SpyderTL: are you familiar with Project Xanadu and the concepts behind xanalogical document storage? One of my primary goals in Kether is to implement xanalogical storage (independent of the current PX code base, but with the idea licensed from Nelson) rather than a file system.

For those unfamiliar with it - which will probably be the majority of those reading this - the idea is simple, but difficult to implement, and often poorly explained (including by Ted Nelson, sadly; while he's good at inspiring enthusiasm, he has a lot of trouble getting the idea across). From a technical perspective, the core of a xanalogical system is a collection of out-of-band internal hyperlinks to fragments of data, each of which holds the information about the source, creation date, size, ownership, visibility and format of the data fragment. Each document consists of several such links.

Sounds sort of like an i-node, right? Well, not really. You see, the data fragments do not form a single document, but are independent of each other, and multiple links can point to a part of any given fragment. Documents in xanalogical storage are logical entities, not structural ones. There is no master directory of documents; rather, documents are built dynamically when requested, and any document can include and share something originally created in another document - a process called transclusion - seamlessly to form a new document.

Data segments are stored permanently in a single (logical) address, and never permanently copied, though they may be mirrored for backup purposes, and may be temporarily copied to a LRU cache for remote access. Copies, whether permanent or temporary, have the same logical address as the original. Networked copies have the same visibility and publication status as the original, and can be served from any existing copy if it is more readily available than the original (such that if a request for a data segment is sent through the network, each system it passes through should check to see if a copy is held locally, and should short-circuit the fetch to use that copy rather than going on to the originating system).

When a document is created, the data in it is journaled, and periodically saved as a new data segment. When a data segment that has been already stored is edited, rather than changing the existing data segment, a new data segment is created with an alternate link to the new segment. This means that (to an extent) there is a record of significant changes to the document, and (among other things) continuous undo for changes.

The hyperlinks are not directly visible, as Web hyperlinks are, but rather are a means by which documents are structured and presented. Presentation of the links themselves is a front-end function, but in most cases they are a back-end entity. The links are bi-directional ('bi-visible' in Xanadu terms), meaning that the presentation software can (if it has permission to and is written to do so) allow the browsing user to follow the link back to the originating document.

I'm a bit short on time right now, but that should give some flavor for it. I can explain more later if needed.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Sockets as a filesystem?
PostPosted: Wed Jul 08, 2015 2:01 pm 
Offline
Member
Member

Joined: Wed Jun 03, 2015 5:03 am
Posts: 397
Schol-R-LEA wrote:
From a technical perspective, the core of a xanalogical system is...

It looks like a graph of chunks of data. And above the graph there is a mechanism that joins some chunks according to some rules. Right?

If yes, then we have just the joining rules beside of the well known graph data structure. Generally speaking, we can select a subgraph and say - it's a new document or whatever we are interested in. But what's new we can see in such approach? Only the old fashioned graph and it's parts. Or is there something special?

_________________
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group