Of course, using UDP is not the same as implementing your own TCP
stack. You just do not need the enormous amounts of sockets even if
you communicate with multiple hosts. And you have to keep track of the
communication yourself because the OS will not do it for you.
Also you would want to decide for each partition if you use it for a
filesystem and mount it, or give access to the partition to a service
or user. Note that mtools use raw floppy devices in exactly this way,
and given the access they can be used for partitions as well.
Thanks
Michal
···
On 14/05/07, Brian Candler <B.Candler@pobox.com> wrote:
On Mon, May 14, 2007 at 11:13:34PM +0900, Michal Suchanek wrote:
> Of course, the FDs are only to organize your IO. You can use TCP ans
> the OS provided sockets, or you can use a single UDP socket and
> maintain the connection state yourself.
If you want to run your own TCP stack you'll need to open a raw socket, and
you can't do that unless you're root, because of the security implications
(e.g. ordinary users could masquerade as privileged services such as SMTP on
port 25)
> Similarly the FDs to open files give you organized access to space on
> a disk drive, and you can always open the partition device and manage
> the storage yourself.
Similarly, only root can have direct access to the raw device. Otherwise,
any user would be able to read any other user's files, modify any file at
whim, totally corrupt the filesystem etc.
Note that accessing the partition and bypassing the filesystem layer
you still use the optimized and balanced drivers. But you do not get
the benefit of organizing your data in the hierarchical namespace the
filesystem provides.
The fact that half of an unix-like system resides in the kernel causes
problems like this. Only filesystems compiled into the kernel can be
mounted. Only root can mount filesystems. Opening too many files is
not allowed because it drains kernel resources. Etc, etc.
Certainly many things have stood the test of time but doubts exist
about their optimal design. For one, the QWERTY layout was designed
for mechanical typewrites that suffered from collisions of the
mechanical parts. It was optimized so that such collisions are
unlikely. Since then new layouts emerged that were optimized for
typing speed. But QWEERTY has stood the test of time, much longer than
UNIX 
Thanks
Michal
···
On 14/05/07, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
On 5/14/07, Michal Suchanek <hramrach@centrum.cz> wrote:
>
> Of course, the FDs are only to organize your IO. You can use TCP ans
> the OS provided sockets, or you can use a single UDP socket and
> maintain the connection state yourself.
>
> Similarly the FDs to open files give you organized access to space on
> a disk drive, and you can always open the partition device and manage
> the storage yourself.
>
> The throughput of the structured IO would be usually lower because the
> OS does already some processing on the data to organize it neatly for
> you.
>
> Limiting the number of FDs per process does not do much to protect the
> kernel memory. Maybe a single process cannot exhaust it but forking
> more processes is easy. It is only a workaround for the poor design
> after all.
I really should let this go because it has nothing much to do with Ruby, but
I don't agree that the Unix IO-access design is a poor one. User programs
should never be accessing raw devices for any reason. It's absolutely not
the case that direct access to raw devices gives you better "performance,"
especially considering how much work is being done by well-optimized device
drivers, and also balanced against the damage you can do by accessing them
yourself. And the design has stood the test of time, having proved its
ability to easily accommodate a wide range of real devices and
pseudo-devices over the years. And Windows even copied the design of the
system calls (even though the underlying implementation appears to be quite
different, except of course for Windows' TCP, which was stolen from BSD).