I need to find the socket options set for a File descriptor.
For example, the accept call returns a FD. I set a number of socket options. Then I need to find if the socket options are actually set for the FD.
P.S: setsockopt is not returning an error, but behavior of fd is not in line with the option. Hence I need to verify this.
You can simply call getsockopt().
Related
Is fs.open/close the only way to get the file descriptor or is there a faster/efficient way?
The reason I close the file is cause I assume I should otherwise I'd end up leaving tones of files open.
fs.open('/my/file.txt','r',function(e,fd){
console.log(fd);//12
fs.close(fd,function(){
fs.fsync(fd,function(){// more code ...
It seems a bit silly to open an close the file just to get an fd but fs.sync requires an fd (a number) instead of string.
I can call close and don't wait for the callback
This way is Asynchronous (non-blocking)
fs.open('/my/file.txt','r',function(e,fd){
console.log(fd);//12
fs.close(fd,function(){});
fs.fsync(fd,function(){// more code ...
I have one file descriptor(basically socket descriptor) example sockfd. I use dup2 to command
(void) dup2(sockfd,0);
then i close the descriptor close(sockfd);
Now i try to receive message on receive recv(0,buf,sizeof(buf),0);
But it is not working whats wrong with it?
dup2 doesn't return void, it returns int, so you should check its return code. If dup2 were failing for some reason and that was the problem then you wouldn't know about it. That being said, dup2 normally always works.
There is one corner case that could cause what you are seeing: if sockfd is already 0. Then you'd be dup2ing 0 to 0 and then closing 0, leaving you with no file descriptor at all. Therefore it's good practice before using dup2 to check whether or not the file descriptor you are trying to renumber is already numbered correctly. But again, this is not likely in your case than sockfd is 0 to begin with.
That being also said, what you are trying to do should work. If it is not, then nobody can answer your question unless you clarify what you mean by "it is not working".
Let's imagine I added non writable fd to epoll watcher to wait when it will become writable.
epoll_ctl(epollfd, EPOLL_CTL_ADD, non_writable_fd, {EPOLLOUT})
non_writable_fd still non writable and epoll_wait will return 0 ready fds
Then I'll make this
dup2(writable_fd, non_writable_fd)
Where writable_fd is a file descriptor which is writable. Now I am expecting that epoll_wait will return 1 fd immediately. But unfortunetly it still timeouts with 0 fd returned.
Why this technique doesn't work with epoll when it works with select and poll?
The problem is that epoll cares about "open file descriptions", not about file descriptors. The answer is hidden in a few layers of man pages. First, epoll_wait:
Will closing a file descriptor cause it to be removed from all epoll
sets automatically?
Yes, but be aware of the following point. A file
descriptor is a reference to an open file description (see
open(2))[...]
Back to your dup2 call:
dup2(writable_fd, non_writable_fd)
dup2 call atomically first closes non_writable_fd and then makes it point to the same file description as writable_fd. Consider 2 cases:
You didn't do anything special so your dup2 ends up closing the open file description associated with non_writable_fd. In this case epoll simply removes it from the set and that's that
You had beforehand dup'd non_writable_fd into something else. In this case dup2 simply severs the association between non_writable_fd and its OFD, which lives on, watched by epoll
In both situations your dup call doesn't achieve what you want: you need to explicitly call epoll_ctl again.
In this code:
open my $fh1,'>','file1';
my $fh1_desc=fileno $fh1;
close $fh1;
open my $fh2,'>','file2';
open my $fh1_,'>&=',$fh1_desc;
if (fileno $fh1_ == fileno $fh2 ) {
print "\$fh1_ and \$fh2 are dups\n";
}
After that $fh1_ and $fh2 point to the same file. How can I detect that the redefinition of file descriptor?
This is "dummy code"! The real case is:
When I pass the file descriptor to a different thread how can I know that it wasn't redefined?
Once you've closed a file handle, the numerical descriptor is meaningless, and will usually just be re-used by the next open, as you've shown. My suggestion is that when you close a file, you make sure to set any handles you may have to 'undef' so you don't fool yourself into thinking they are still valid.
But I may have misunderstood your problem - you didn't supply very much detail.
I found this line in a script. While I globally understand what it does--opening a bidirectional TCP connection--, I need some explanations on the syntax. Here's the line:
exec 5<>"/dev/tcp/${SERVER}/${PORT}"
And my questions:
< and > are usually used to redirect IOs. What does it mean there? Is it usable in another context? How?
Why does it work, while /dev/tcp doesn't exists?
Why 5? Can it be another number? What are the values allowed?
Why is exec necessary? (given nothing is actually executed)
Thanks.
< and > are usually used to redirect IOs. What does it mean there? Is it usable in another context? How?
It's the same - input and output is redirected to fd 5.
Why does it work, while /dev/tcp doesn't exists?
It's a special file: If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a TCP connection to the corresponding socket.
Why 5? Can it be another number? What are the values allowed?
Yes, it can be any value, but you need to ensure you don't use an fd already in use.
Why is exec necessary? (given nothing is actually executed)
exec means the redirection happens in the current shell, not within a subshell.
I can only answer for the exec part:
exec without a command given may be used to change I/O redirections. <> in this case means open for read+write. 5 is the channel number (or file descriptor). This makes sense if other commands send their output / read their input from channel 5.
For "/dev/tcp/${SERVER}/${PORT}" I don't know if it's a feature of a specific Linux version or if it's a bash feature (I assume the latter).
-- EDIT: from the bash manual page: --
Bash handles several filenames specially when they are used
in redirections, as described in the following table:
/dev/fd/fd
If fd is a valid integer, file descriptor fd is
duplicated.
/dev/stdin
File descriptor 0 is duplicated.
/dev/stdout
File descriptor 1 is duplicated.
/dev/stderr
File descriptor 2 is duplicated.
/dev/tcp/host/port
If host is a valid hostname or Internet address,
and port is an integer port number or service
name, bash attempts to open a TCP connection to
the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address,
and port is an integer port number or service
name, bash attempts to open a UDP connection to
the corresponding socket.