Hi,
I have an application I’m trying to create on QNX 6.2.1. It has a process
that opens a TCP socket, sets socket options, binds to a well-known port,
listens, accepts a connection, then duplicates the file descriptor. Next,
it creates two threads; the first one which is a server and which uses the
“read” socket to “recv” packets, and, a second one which uses the duplicated
socket descriptor to send packets. At some point, I need to shut this
process down and spawn another process that needs to use the same well-known
TCP port. My problem is that the original process sometimes simply won’t
terminate and this occurs when there are packets that have been recently
recv’d. In this case, netstat shows the connection is ESTABLISHED (not
TIME_WAIT because the process is still alive), and, this perists until I
terminate the client’s connection (on the client computer). I’ve tried just
about everything, including variations on having the original process use
“shutdown” followed by “close”, setting the socket options for SO_LINGER to
indicate that unsent data should be immediately discarded, using KILL to
send a SIGKILL signal and drinking scotch until I can’t see straight
(doesn’t seem to help either).
So, sorry to be so long-winded, but here are my questions:
- Is this behavior peculiar to QNX, or, would I expect to see the same
thing on Linux or a Unix implementation?
- Do you have any bright ideas that might help (right now, the best I can
do is to re-architect my app to make it unnecessary to shutdown the original
process)?
Thanks,
Eric Franz
Ricanz Corporation
Do you have a test case? Which stack are you using?
Regards,
-seanb
Eric Franz <ricanz58@yahoo.com> wrote:
Hi,
I have an application I’m trying to create on QNX 6.2.1. It has a process
that opens a TCP socket, sets socket options, binds to a well-known port,
listens, accepts a connection, then duplicates the file descriptor. Next,
it creates two threads; the first one which is a server and which uses the
“read” socket to “recv” packets, and, a second one which uses the duplicated
socket descriptor to send packets. At some point, I need to shut this
process down and spawn another process that needs to use the same well-known
TCP port. My problem is that the original process sometimes simply won’t
terminate and this occurs when there are packets that have been recently
recv’d. In this case, netstat shows the connection is ESTABLISHED (not
TIME_WAIT because the process is still alive), and, this perists until I
terminate the client’s connection (on the client computer). I’ve tried just
about everything, including variations on having the original process use
“shutdown” followed by “close”, setting the socket options for SO_LINGER to
indicate that unsent data should be immediately discarded, using KILL to
send a SIGKILL signal and drinking scotch until I can’t see straight
(doesn’t seem to help either).
So, sorry to be so long-winded, but here are my questions:
- Is this behavior peculiar to QNX, or, would I expect to see the same
thing on Linux or a Unix implementation?
- Do you have any bright ideas that might help (right now, the best I can
do is to re-architect my app to make it unnecessary to shutdown the original
process)?
Thanks,
Eric Franz
Ricanz Corporation
I’m using the “standard” TCP stack; I start io-net via “io-net -ptcpip”. I
will put together a test case tonight.
Thanks,
Eric
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:d1rt16$86n$1@inn.qnx.com…
Do you have a test case? Which stack are you using?
Regards,
-seanb
Eric Franz <> ricanz58@yahoo.com> > wrote:
Hi,
I have an application I’m trying to create on QNX 6.2.1. It has a
process
that opens a TCP socket, sets socket options, binds to a well-known port,
listens, accepts a connection, then duplicates the file descriptor.
Next,
it creates two threads; the first one which is a server and which uses
the
“read” socket to “recv” packets, and, a second one which uses the
duplicated
socket descriptor to send packets. At some point, I need to shut this
process down and spawn another process that needs to use the same
well-known
TCP port. My problem is that the original process sometimes simply won’t
terminate and this occurs when there are packets that have been recently
recv’d. In this case, netstat shows the connection is ESTABLISHED (not
TIME_WAIT because the process is still alive), and, this perists until I
terminate the client’s connection (on the client computer). I’ve tried
just
about everything, including variations on having the original process use
“shutdown” followed by “close”, setting the socket options for SO_LINGER
to
indicate that unsent data should be immediately discarded, using KILL to
send a SIGKILL signal and drinking scotch until I can’t see straight
(doesn’t seem to help either).
So, sorry to be so long-winded, but here are my questions:
- Is this behavior peculiar to QNX, or, would I expect to see the same
thing on Linux or a Unix implementation?
- Do you have any bright ideas that might help (right now, the best I
can
do is to re-architect my app to make it unnecessary to shutdown the
original
process)?
Thanks,
Eric Franz
Ricanz Corporation
Sean Boudreau wrote:
Do you have a test case? Which stack are you using?
Regards,
-seanb
Eric Franz <> ricanz58@yahoo.com> > wrote:
Hi,
I have an application I’m trying to create on QNX 6.2.1. It has a process
that opens a TCP socket, sets socket options, binds to a well-known port,
listens, accepts a connection, then duplicates the file descriptor. Next,
it creates two threads; the first one which is a server and which uses the
“read” socket to “recv” packets, and, a second one which uses the duplicated
socket descriptor to send packets.
Why duplicate the file descriptor? That’s not necessary to
allow two threads in the same process to use it.
John Nagle
Team Overbot
Eric Franz <> ricanz58@yahoo.com> > wrote:
Hi,
I have an application I’m trying to create on QNX 6.2.1. It has a process
that opens a TCP socket, sets socket options, binds to a well-known port,
listens, accepts a connection, then duplicates the file descriptor. Next,
it creates two threads; the first one which is a server and which uses the
“read” socket to “recv” packets, and, a second one which uses the duplicated
socket descriptor to send packets.
Why duplicate the file descriptor? That’s not necessary to
allow two threads in the same process to use it.
John Nagle
Team Overbot
Yes, and the socket destruction doesn’t start in the stack until the
last dup is closed. I don’t understand your signal issue though…
Regards,
-seanb