[Twisted-Python] LineReceiver Protocol

[Eric Mangold]

> Christopher Armstrong wrote:
>> On Sat, 20 Nov 2004 23:12:18 -0800, Michael Mata
>> <michael.mata at gaigen.net> wrote:
>>
>>>Is there a way to extend the LineReceiver protocol to take action on a
>>>continued, periodic basis?  Currently, the protocol only does work when
>>>a line is received.  However, there are times when the script should
>>>take action without waiting to receive a line.
>>
>>
>> It doesn't have anything to do with the protocol; what you want is
>> reactor.callLater(seconds, functionToCall)
>>
>> http://twistedmatrix.com/documents/current/howto/time has more
>> information.
>>
>>
>>>Another example might be a global message that needs to be sent to all
>>>connections.  The message would have to be stored in  message queue and
>>>sent only when lineReceived is called.  It would be nice if the message
>>>could instead be sent imediately even if the connection was currently
>>> idle.
>>
>>
>> For this you just want to keep track of all the protocols you want to
>> send stuff to. doc/examples/chatserver.py shows how to do this.
>> basically, in your lineReceived, you can do something like "for prot
>> in self.factory.protocols: prot.sendMessage(line)".
>>
>>
>
> The function task.LoopingCall(runEverySecond) from twisted.internet
> looks like a good fit for scheduling recurring maintenance.
>
> If I follow chatserver.py, data globally available to all protocols
> should be stored in the reactor.

No, the reactor is pretty much off-limits for storing user data :)
You should store such information in your client Factory.
You can use the Factory's buildProtocol method to do per-protocol
record keeping.

>  I'm guessing that if I want data
> associated to a specific instance of a protocol, I should store it in a
> variable under the protocol's __init__ function.

Sure, that's fine, and you can pass state in to your Protocol instances
when you build them from your Factory's buildProtocol.

> For example, I'd give a protocol a session id upon connection and add it
> to the client list in the reactor.  Now if I want to send a message to
> that client, I'd iterate throught the list in the reactor until I find
> the one with correct session id.

Sure, except s/reactor/Factory/

-Eric