This question already has answers here:
What are file descriptors, explained in simple terms?
(13 answers)
Closed 8 years ago.
Are C socket descriptor returned by socket() function unique ?
I called this from two programs simultaneously and i got the same output
(socDes = socket(PF_INET, SOCK_MRP, 0)
printf("%d",socDes);
According to its man page, socket() returns a file descriptor for New socket
if two programs have same socket, how the received packets gets transferred to different process ? Any elaboration will be helpful.
Socket descriptors are file system handles, and should be unique to your process for the duration of it's session. But if you end and re-run, you may very well receive the same value.
Keep in mind, each process has it's own list of file system handles. So file descriptor 3 in process 10 can be very different from file descriptor 3 in process 20.
A file descriptor is a process resource. Every program loaded in your system has it's own, independent set of file descriptors. That's why STDOUT/STDIN correspond to FD 1/2 (or is it 0/1?). In practice file descriptors are numeric identifiers to a resource held by the operating system, they just happen to be printable as integers (there's no guarantee about that on all systems, what you're seeing is an implementation detail). In the operating system your FD 1,2,3,etc correspond to different resources than in another process.
Since each process has its own pool of resources it follows that file descriptors would be in separate pools. They just happen to have the same ID because of how those IDs are allocated by the OS!
Related
This question already has answers here:
Can I share a file descriptor to another process on linux or are they local to the process?
(6 answers)
Closed 6 years ago.
int fd = socket(//arguments);
Can this descriptor be passed to another process via IPC and still be valid or is it local to the process that created it?
File descriptors are local to the process. For instance, every process will have its standard input, output, and error on file descriptors 0, 1, and 2.
It is possible to pass a file descriptor to another process over a UNIX domain socket. When this is done, each process will have a copy of the file descriptor, possibly under a different FD number. It's a kind of messy API, though, and is rarely used.
Yes, file descriptors are local to the process. When a process forks a child, however, the parent and child have the same file descriptor table. This is great because it allows for IO redirection, which is a pretty handy trick.
While trying to learn socket programming, I saw the following code:
int sock;
sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
I browsed through the man page and found that socket returns a file descriptor. I have tried searching the internet and other similar questions here but I couldn't understand what file descriptor really is. That would be great if someone could explain file descriptor in easy language.
There are two related objects: file descriptor and file description. People often confuse these two and think they are the same.
File descriptor is an integer in your application that refers to the file description in the kernel.
File description is the structure in the kernel that maintains the state of an open file (its current position, blocking/non-blocking, etc.). In Linux file descripion is struct file.
POSIX open():
The open() function shall establish the connection between a file and a file descriptor. It shall create an open file description that refers to a file and a file descriptor that refers to that open file description. The file descriptor is used by other I/O functions to refer to that file. The path argument points to a pathname naming the file.
The open() function shall return a file descriptor for the named file that is the lowest file descriptor not currently open for that process. The open file description is new, and therefore the file descriptor shall not share it with any other process in the system.
In Unix/ Linux operating systems, a file descriptor is an abstract indicator (handle) used to access a file or other IO(input/output) resource, such as a pipe or network socket.
Normally a file descriptors index into a per-process file descriptor table maintained by the kernel in Linux/Unix OS, that in turn indexes
into a system-wide table of files opened by all processes, called the file table.
This table records the "mode" with which the file or the other resource has been opened
for the following operations(There are more operations)
reading
writing
appending
writing
and possibly other modes.
It also indexes into a third table called the inode table that describes the actual underlying files.
File Descriptors are nothing but mappings to a file. You can also say these are pointers to a file that the process is using.
FDs are just integer values which act as pointers to process resources.
Whenever a process starts, an entry of the running process is added to the /proc/<pid> directory. This is the place where all of the data related to the process is kept. Also, on process start the kernel allocates 3 file-descriptors to the process for communication with the 3 data streams referred to as stdin, stdout and stderr.
the linux kernel uses an algorithm to always create a FD with the lowest possible integer value so these data-streams are mapped to the numbers 0, 1 and 2.
Let's say in you code you opened a file to read from or to write to. This means the process needs access to a resource and it has to create a mapping/pointer for this new resource.
To do this, the kernel automatically creates a FD as soon as the file is opened by your code.
If you run ls -l /proc/<pid>/fd/ you will se an additional FD created there with id 4 (can be some other number also if the program has used other resources)
I think of file descriptors as (indirect, higher-level) pointers to opaque file objects maintained by the kernel.
Normally, when you deal with objects maintained by a library, you pass to the library pointers to objects that you're not supposed to dereference and manipulate yourself.
For kernel objects, this it's not just that you're not supposed to manipulate them yourself -- you literally can't because they live in a different address space that's not at all accessible to you. And because they live in a different address space, pointers wouldn't be a meaningful way of referring to them.
You need a token or handle which the kernel would internally resolve to a pointer that's meaningful in the kernel address space. File descriptors are such tokens in integer form.
For the kernel:
your_process_id + your_file_descriptor => kernels_file_object_pointer
(or an EBADF error if a given filedescriptor may not be resolved to a file object pointer for the given process)
When using the open() function in C, I get a fd (file descriptor). I was wondering if it's the same thing as its process id, because as I know, fd is an integer.
No it is not.
PID is process identifier, and file descriptor is file handler identifier.
Specifically from Wikipedia about File Descriptors:
(...) file descriptor (FD) is an abstract indicator for accessing a file. The term is generally used in POSIX operating systems.
In POSIX, a file descriptor is an integer, specifically of the C type int. (...)
And for PID:
[PID] is a number used by most operating system kernels, — such as that of UNIX, Mac OS X or Microsoft Windows — to temporarily uniquely identify a process (...)
No, file descriptors are indices into the file table of your own process. They are always small integers (that is, up to the max-open-files limit for the process) because, among other things, the bitmap interface to select() wouldn't work if they were arbitrary numbers. On the other hand PIDs typically grow to at least 32767 before the wrap around.
An open file in general doesn't have a process ID of its own. And even in the case where one might arguably expect it to be connected to a particular process -- namely when the file handle comes from popen() -- there's no such direct connection and what goes on inside popen() is more complex than "treat this process as if it was a file".
No...
A file descriptor is an opaque handle that is used in the interface between user space and the kernel to identify file/socket resources. Therefore when you use open() or socket() (system calls to interface to the kernel) you are returned a file descriptor, which is an integer (it is actually an index into the processes u structure - but that is not important). Therefore if you want to interface directly with the kernel, using system calls to read(), write(), close() etc. the handle you use is a file descriptor.
A PID (i.e., process identification number) is an identification number that is automatically assigned to each process when it is created on a Unix-like operating system.A process is an executing (i.e., running) instance of a program. Each process is guaranteed a unique PID, which is always a non-negative integer.
One of the first things a UNIX programmer learns is that every running program starts with three files already opened:
Descriptive Name.............fd number...................... Description
Standard In 0 Input from the keyboard
Standard Out 1 Output to the console
Standard Error 2 Error output to the console
If you create any file descriptor, mostly you will get value as 3. Because 3 is least available +ve integer to allocate for fd. Because STDIN,STDOUT,STDERR are occupied with 0,1,2 respectively. That is why fd is called as smallest non negative integer.
This question already has answers here:
Portable way to pass file descriptor between different processes
(2 answers)
Closed 9 years ago.
The answer to this question shows how to share a file descriptor between two processes. I am unclear on whether this is possible with any process or only related processes. For example, is it possible to open an unnamed pipe and pass the read or write file descriptor to another unrelated process on a unix system?
Yes, you can pass a file descriptor to any other process. The only requirement is that you open a Unix domain socket to communicate between the two processes.
This question already has an answer here:
C : "same file descriptors of all client connections" (client server programming)
(1 answer)
Closed 8 years ago.
As the argument of accept() for new client socket,
the listener socket is in shared memory area and is shared by all forked server processes.
but each server processesaccept()returns the same socket descriptor afteraccept()` is called by all different forked processes.
Does the fork() also makes separate area for socket descriptors and each forked process
manage the area separately?
Is that why they produce duplicate socket descriptors?
I intended to use select() to detect changes on all socket descriptors,
but because they produce all same descriptors, I couldn't make it out..
Yes, socket descriptors' (as well as file descriptors) values are managed on a per-process base.