<time has passed until server decides it needs to send a plugin to one of the clients> Server sends plugin to Client 1
"until server decides" is your 'event' here, not anything initiated by the client. The way I see your issue here is that you seem to believe that only client actions raise events in your application, which is not really the case. Any part of your application might be responsible for an event on which you have to act by sending data to the client. In that case, when a client connects and your factory instantiates an instance of the protocol ( a new client connection), you should keep a reference to that instance in a way depending on your application needs. Through this reference you can send data to your clients at any point in time, corresponding to events raised from another part of your application. For example - I've a simple notification service on which a number of clients connect and subscribe for events for specific users. I keep a mapping of every connected client and its subscriptions in my application code. In my case, the events are raised through a second protocol that informs my server for every user action, then I send packets to the connected clients, based on the mappings. But the actual cause of your events can be anything you like - other network sources, database, anything you need to code. Basically - your protocol class is responsible only for how data is transferred to and from the client. Your application logic should be defined at a higher level, through your factory and service classes. A single service might be communicating with clients trough different protocols. I hope that clear is up somewhat. The examples for the finger server in twisted's documentation might give you a good idea of how things work - they're structured nicely over a few chapters to evolve a dumb server into a useful full-fledged application. Also - the IRC server/client examples can give you a good idea of how you send data to a connected client, based on an event created from another source.