Michael,
I was looking through the UDP_ng code. Maybe I missed something, but
I can't find any tear down code. SimplePeer, TargettedPeer,
PostboxPeer; all three exit their while loop in response to a
shutdownMicroprocess, but they don't clean anything up.
Since my problem is they don't release their ports, I tried adding a
simple self.sock.close() immediately after the main while loop. With
this change, the peers release their sockets on shutdown and I don't
get an exception when the same port number rolls around.
So, I think adding sock.close() is a good thing. After this change
though I get intermittant (1s-10m) bad file descriptor exceptions
thrown from line 312 of Selector.py.
I tried adding remove messages to the selector service prior to the
close, but I still sometimes get a bad file descriptior exception.
Have I missed something? After my while loop, I have now:
self.send(removeWriter(self, ((self, "writeReady"),
self.sock)),
"_selectorSignal")
yield 1
self.send(removeReader(self, ((self, "readReady"),
self.sock)),
"_selectorSignal")
yield 1
self.sock.close()
Digging a little deeper, it looks like despite sending the messages
prior to the close, the messages are read and acted upon after the
close. Which is probably why sometimes it barfs when it tries to do
something with the descriptor and it doesn't know the socket is
closed.
Thanks,
Steve
On Mar 2, 1:36 pm, Steve <unetright.thebas...@xoxy.net> wrote:
> I'm running on Vista, so again maybe this is a windows specific
> problem. I have two different application codes that work
> similarly. One is a server that rotates through a range of ports.
> It creates a UDP Peer on a port, waits for data, and after a time
> sends a shutdownMicroprocess and rotates to the next port.
>
> The problem is that my software firewall shows these local ports are
> never relinquished. In in fact, if I wait long enough the rotate
> algorithm goes through 1000 ports and starts back over. When that
> happens I get an exception that the requested port is already bound.
> In the server code I used UDP_ng.TargettedPeer, but I think it's a
> problem in the basic peer code.
>
> The second program is a client side version. It does the same thing
> except it binds to a port, sends data, waits for a response, rotates,
> etc. The result is the same thing. The ports are never
> relniquished. In the client side code I used UDP_ng.SimplePeer, but
> again I think it's in the base code.
>
> At one point I added an extra ._isStopped() check (it wasn't stopped)
> and then called the .stop() method. This indeed stopped the
> microprocess but still left the port bound.
>
> Any ideas? Could this be related to the TCP ignored connection bug
> that I was describing in another thread?
>
> Thanks,
> Steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"kamaelia" group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to
kamaelia+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---
