On Sunday 01 March 2009 06:51:09 Gloria W wrote: > Hi all, > I am testing things, trying to get a small modification to this example > working correctly: http://www.kamaelia.org/Home
By this, I'm assuming you mean this: http://pastebin.com/m529b7499 > I've simple added this line: > > self.send("Testing..1.2.3...",'outbox') > > between these two lines: > > > while not self.doShutdown(): > if self.dataReady("inbox"): Like this? http://pastebin.com/m70a968b7 ie (diff) : http://pastebin.com/pastebin.php?diff=m70a968b7 > and it does nothing. yielding it also does nothing. I should be able to > write to the console without receiving data from it, I hope. What am I > missing? I'm not sure. The pastebin above works. (floods the screen with "Testing..1.2.3..." ) > Also, this is interesting: > ChatServer(port=1501).run() ... > "/usr/lib/python2.5/site-packages/Kamaelia/Internet/TCPServer.py", line > 144, in makeTCPServerPort s.bind((HOST,PORT)) > File "<string>", line 1, in bind > socket.error: (98, 'Address already in use') > > > It locks the port for about a minute after every run, then finally frees > it, this error goes away, and I can finally reconnect. That's normal and part of the TCP stack's normal behaviour. In that 60 seconds, if you quickly type: netstat -natp |grep TIME_WAIT You'll see a line like this: tcp 0 0 127.0.0.1:1500 127.0.0.1:48846 TIME_WAIT >From this diagram: http://ssfnet.org/Exchange/tcp/Graphics/tcpStateDiagram1.gif You'll see that if the server side ends up in this state (bottom middle of the diagram) that it's expected to wait for 2 segment lifetimes ... which is your 60 seconds. Can you change this behaviour ? Yes. 2 ways: 1) on the system globally. Generally considered a bad idea, unless you really know what you're doing. 2) Change the behaviour of the server to say "yes, allow this port to be reused, even within the 2 segment lifetimes". The latter you do by changing the socket options. Assuming you've done this: class ChatServer(ServerCore): .... You add in this: class ChatServer(ServerCore): socketOptions=(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) .... Alternatively, if you don't want change the ChatServer class definition, you can change this line: > ChatServer(port=1501).run() To: ChatServer(port=1501, socketOptions=(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) ).run() One thing I've thought about several times is whether this reuse of the socket address should be the default or not. There are pros and cons. Pros: 1 Don't have this explanation periodically :) 2 Allows instant server respawn 3 Simplifies many setups Cons: 1 When it goes wrong harder to explain why :) 2 Instant server respawn means that clients connected which are expecting segments can get confused. Generally this means they'll get a socket error and need to reconnect. That said, if the server restarts, that'd be necessary anyway, with or without the MSL behaviour. - Specifically what's happening in this scenario is the server is shutting down without the clients being disconnected, leaving each connection in an unexpected state, hence the TIME_WAIT state on the server socket. 3 Need a way of switching off this behaviour. Personally I think pro.3 outweighs everything else, but I don't generally like reusing default behaviours. > Thanks in advance for your help! You're welcome :) Michael. -- http://yeoldeclue.com/blog http://twitter.com/kamaelian http://www.kamaelia.org/Home --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
