Close a socket externally

[drs]

Hi,

I have a program which opens a socket server in a thread. I need for the
server to listen on the socket for a certain amount of time (say, ten
seconds or so) and then close it, and am wondering if there is a good way to
close the socket other than sending it a message from another thread to
close itself. That is, I am looking for a way to forcably kill a socket
from a second thread, not to send it a message to kill itself.

Thanks,

-drs

 

[Michael Fuhr]

I have a program which opens a socket server in a thread. I need for the
server to listen on the socket for a certain amount of time (say, ten
seconds or so) and then close it, and am wondering if there is a good way to
close the socket other than sending it a message from another thread to
close itself. That is, I am looking for a way to forcably kill a socket
from a second thread, not to send it a message to kill itself.

Why the requirement to close the socket from another thread? Why
can't the thread that created the socket time out and close the
socket itself?

 

[Jeremy Bowers]

I have a program which opens a socket server in a thread. I need for the
server to listen on the socket for a certain amount of time (say, ten
seconds or so) and then close it, and am wondering if there is a good way to
close the socket other than sending it a message from another thread to
close itself. That is, I am looking for a way to forcably kill a socket
from a second thread, not to send it a message to kill itself.

Speaking generally, I would be surprised if this existed, because it would
basically be a security hole. Not quite literally, but it definitely feels
wrong.

The only way to do it that I can think of is for your program to interpose
itself and act as a proxy between the other two. Then you can close it the
*two* sockets anytime you want, for any reason. You could also separate
the proxy part from the control part by leaving a control port open on the
proxy. This has obvious issues, notably bandwidth, but short of major
kernel patching I think this is your choice.

Or, more likely, your architecture needs a bit of restructuring.

I might be wrong, but if I am, I register my surprise in advance. Also, it
is going to be very, very platform specific and you don't mention what
platform you are on.

 

[bryanjugglercryptographer]

I have a program which opens a socket server in a thread. I need for the
server to listen on the socket for a certain amount of time (say, ten
seconds or so) and then close it, and am wondering if there is a good way to
close the socket other than sending it a message from another thread to
close itself.

Yes, you can either set a timeout on the socket, or use
select.select() with a timeout. When waiting for new
connections, a socket will select as readable when a new
connection arrives.

That is, I am looking for a way to forcably kill a socket
from a second thread, not to send it a message to kill itself.

The timeout/select solution is along different lines, but if I
understood your initial statement of the problem, it's how most
sockets programmers do that kind of thing.

 

[drs]

Yes, you can either set a timeout on the socket, or use
select.select() with a timeout. When waiting for new
connections, a socket will select as readable when a new
connection arrives.


The timeout/select solution is along different lines, but if I
understood your initial statement of the problem, it's how most
sockets programmers do that kind of thing.

My understanding of using a timeout is that the clock starts running only
when there is no communication. I actually need a hard limit on the time a
socket is open, and while the best option might be to at least allow the
current read/write cycle to complete, I am not necessarilly adverse to just
cutting off the socket.

To explain, I am working on an agent based modeling project where agents
communicate and exchange over TCP sockets. Agents have to "buy" the right
to open sockets, so I need an enforcement mechanism to shut them down when
their time expires.

I am not familiar w/ select, so i'll go look into that.

-drs

 

[Jeff Shannon]

To explain, I am working on an agent based modeling project where agents
communicate and exchange over TCP sockets. Agents have to "buy" the right
to open sockets, so I need an enforcement mechanism to shut them down when
their time expires.

Would it work to limit the number of bytes that they're allowed to
send/receive, instead of time? Especially given that TCP's delivery
guarantees mean that the transfer times for a given chunk of data can't
really be predicted (because it may include any number of
retransmissions), it seems that byte-count might be a more "fair" way of
allocating communication. Of course, this depends on how much control
you have over the specifications...

Jeff Shannon
Technician/Programmer
Credit International

 

[bryanjugglercryptographer]

The method I like is to compute a deadline for all the action on
the socket, then compute a new timeout for each blocking
operation. The following isn't tested, or even compiled, but it
shows the idea:

deadline = time.time() + hard_limit_on_the_time
while stuff_to_do:
timeout = deadline - time.time()
if timeout < 0:
break # time limit expired
(readable, _, _) = select.select([mysock], [], [], timeout)
if ! readable:
break # time limit expired
# at this point mysock has data available (barring weird
things)

 

[Bryan Olson]

> The following isn't tested [...]

Web-posting screwed up the indentation. It should read:

deadline = time.time() + hard_limit_on_the_time
while stuff_to_do:
timeout = deadline - time.time()
if timeout < 0:
break # time limit expired
(readable, _, _) = select.select([mysock], [], [], timeout)
if ! readable:
break # time limit expired
# at this point mysock has data available (barring weird things)