Hi Friends,

I've a question,

I just want to know if a socket descriptor (for eg descriptor 3) is
already allocated or not ?
Because based on that information I need to close a particular socket.

Kernel would be allocating only free socket descriptors whenever we
creates a socket using socket() system call. How it does that
checking?

Any information would be highly appreciated.

Thanks,
Sojin

On May 8, 12:10 am, soj <jul....@gmail.com> wrote:
> Hi Friends,
>
> I've a question,
>
> I just want to know if a socket descriptor (for eg descriptor 3) is
> already allocated or not ?
> Because based on that information I need to close a particular socket.
>
> Kernel would be allocating only free socket descriptors whenever we
> creates a socket using socket() system call. How it does that
> checking?


The kernel has some sort of internal magic way of tracking open
descriptors. Your specific OS might provide you with some API that
allows you to determine if a specific descriptor is valid. You might
get away with doing something like a getsockopt() against the
descriptor in question, although what exactly that will do with an
invalid descriptor is going to be system specific.

Anyway, there's almost no reason why you'd actually want to do this,
requests like this usually start with faulty application logic. If
you need to track the state of a socket, you need to do so in your
application. The problem is that socket handles can be reused, and
you have no way of knowing if "descriptor 3" isn't being used
(validly) by some other part of your application. That descriptor
could be reused from your own code on a new connection, or perhaps
some other part of your application (or a library you use) might have
opened it.

In short knowing that "descriptor 3" is open, tells you almost nothing
of value, because there is no way to determine *why* it's open, or by
what part of your program. This gets even worse in threaded
applications. If you think you need to know this, you almost
certainly have a bug in your application.

On May 8, 10:37 am, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:
> On May 8, 12:10 am, soj <jul....@gmail.com> wrote:
>
> > Hi Friends,
>
> > I've a question,
>
> > I just want to know if a socket descriptor (for eg descriptor 3) is
> > already allocated or not ?
> > Because based on that information I need to close a particular socket.
>
> > Kernel would be allocating only free socket descriptors whenever we
> > creates a socket using socket() system call. How it does that
> > checking?
>
> The kernel has some sort of internal magic way of tracking open
> descriptors. Your specific OS might provide you with some API that
> allows you to determine if a specific descriptor is valid. You might
> get away with doing something like a getsockopt() against the
> descriptor in question, although what exactly that will do with an
> invalid descriptor is going to be system specific.
>
> Anyway, there's almost no reason why you'd actually want to do this,
> requests like this usually start with faulty application logic. If
> you need to track the state of a socket, you need to do so in your
> application. The problem is that socket handles can be reused, and
> you have no way of knowing if "descriptor 3" isn't being used
> (validly) by some other part of your application. That descriptor
> could be reused from your own code on a new connection, or perhaps
> some other part of your application (or a library you use) might have
> opened it.
>
> In short knowing that "descriptor 3" is open, tells you almost nothing
> of value, because there is no way to determine *why* it's open, or by
> what part of your program. This gets even worse in threaded
> applications. If you think you need to know this, you almost
> certainly have a bug in your application.

Thanks for your comments,

I'm using linux 2.6 kernel, for my protocol stacks.
The application doesnt want a STDIN and closes that. But lower layer
stack is reusing (by socket or accept system calls) the descriptor "0"
and application is trying to close it again.
Any way I got ride of this situation with a simple logic in
application (by checking the type of the descriptor).

Thanks a lot
Sojin

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> wrote:
> In short knowing that "descriptor 3" is open, tells you almost nothing
> of value, because there is no way to determine *why* it's open, or by
> what part of your program.

It's funny that this came up today, because I was struggling with this
exact issue yesterday.

I've written a C++ class which manages a socket. Part of the specification
is that the socket is closed when the object is destroyed. I was looking
for a way to write a unit test which verifies that a given socket
descriptor is valid, then destroys the object under test, then verifies
that the descriptor was closed. The best I came up with was to just close
the descriptor myself; it I got EBADF, that meant it was already closed
(and the test passed).

I'll admit, however, that while that worked in the specific case of a
(single-threaded) unit test, it might not be a good plan in a more general
environment.

In article <1178608568.998717.231860@e65g2000hsc.googlegroups .com>,
soj <jul.sfx@gmail.com> wrote:

>I'm using linux 2.6 kernel, for my protocol stacks.
>The application doesnt want a STDIN and closes that. But lower layer
>stack is reusing (by socket or accept system calls) the descriptor "0"
>and application is trying to close it again.

The standard way of handling this old familiar problem is something like:

fd = open("/dev/null", O_RDONLY)
dup2(fd, 0);

(of course, with error checking on system calls,
and probably "STDIN_FILENO" instead of "0")

Reading source is a good thing. For example, if you read the source
for an implementation of the libc daemon() function, you'll probably
find similar work on stdout and stderr.


Vernon Schryver vjs@rhyolite.com