Re: [Twisted-Python] writing back through open connections
Matt, I read that howto/servers documentation and I have set up my code into a Factory and Protocol that handles incoming connections. I don't think I explained myself well enough though. When a client connects, the server may or may not being send data back right away so I need to be able to send data to that connected client on the servers terms. For example: Client 1 connects -- Factory instantiates Protocol class to handle communication (connection doesn't close) Client 2 connects -- Factory instantiates Protocol class to handle communication (connection doesn't close) <time has passed until server decides it needs to send a plugin to one of the clients> Server sends plugin to Client 1 So how can that server send data to client 1 if client 1 hasn't caused an event (The server side causes a certain event it should send data to a selected client). I understand that if a client sends data to the server I can than write back to the client using the dataReceived function within the Protocol instantiation. In this case once N number of agents have connected I want the server to push data to the clients without the Client writing to the server. Thanks again for the help.
On Tue, Mar 4, 2008 at 11:42 PM, David Welch <dwelch@umail.ucsb.edu> wrote:
Matt,
I read that howto/servers documentation and I have set up my code into a Factory and Protocol that handles incoming connections.
Honestly, I don't think we're dealing with a design pattern issue now.
I don't think I explained myself well enough though. When a client connects, the server may or may not being send data back right away so I need to be able to send data to that connected client on the servers terms. For example:
Client 1 connects -- Factory instantiates Protocol class to handle communication (connection doesn't close) Client 2 connects -- Factory instantiates Protocol class to handle communication (connection doesn't close) <time has passed until server decides it needs to send a plugin to one of the clients> Server sends plugin to Client 1
So how can that server send data to client 1 if client 1 hasn't caused an event (The server side causes a certain event it should send data to a selected client).
Define `event'. Is the initial connection not an event? If you have an open connection, the client doesn't have fart back through it every 5 seconds (by the semantics of most protocols) to keep it open or anything.
I understand that if a client sends data to the server I can than write back to the client using the dataReceived function within the Protocol instantiation.
Are you sure you understand? You're calling dataReceive to send data? If you're calling a method (that's what you meant by "function within the Protocol instantiation", I guess) with "receive" in the name, then you can only be very confused.
In this case once N number of agents have connected I want the server to push data to the clients without the Client writing to the server. Thanks again for the help.
So write back data to the client. That's all I can say until you describe what you've tried (w/ code) and why it failed (w/ a stacktrace) - vs. in pretty vague terms on essay on what you want to do and haven't even attempted. -- \\\\\/\"/\\\\\\\\\\\ \\\\/ // //\/\\\\\\\ \\\/ \\// /\ \/\\\\ \\/ /\/ / /\/ /\ \\\ \/ / /\/ /\ /\\\ \\ / /\\\ /\\\ \\\\\/\ \/\\\\\/\\\\\/\\\\\\ d.p.s
Forgive any newbie errors, as I'm new to Twisted. The pattern discussed *seems* to be the same as the 'comet' pattern in web development: a client contacts the server, but rather than responding quickly, the server 'files away' the connection in case there is something to send later. (Filing away, in my case is done by adding a reference to the stream as a member of a 'Connection' class withing my server. 'Connections' can either be 'open' [able to send immediately] or 'buffering' [waiting for the client to reconnect].) I have implemented this pattern using twisted.web2 as follows: A render method creates a stream, but 'files it away', rather than calling stream.finish(). The render method *does* complete and return, but the connection is thereby held open and no data is immediately sent. Sometime later, or perhaps never, something happens on the server which causes it to send data on the previously 'filed away' stream and calls stream.finish(). (In my case, because this is comet, the client immediately makes another connection to the server, which is again 'filed away'.) I hope this doesn't muddy the issue. Regards, Chris, P.S. I have heard of Nevow Athena, but I wanted something very simple. On 05/03/2008, Drew Smathers <drew.smathers@gmail.com> wrote:
On Tue, Mar 4, 2008 at 11:42 PM, David Welch <dwelch@umail.ucsb.edu> wrote:
Matt,
I read that howto/servers documentation and I have set up my code into a Factory and Protocol that handles incoming connections.
Honestly, I don't think we're dealing with a design pattern issue now.
I don't think I explained myself well enough though. When a client connects, the server may or may not being send data back right away so I need to be able to send data to that connected client on the servers terms. For example:
Client 1 connects -- Factory instantiates Protocol class to handle communication (connection doesn't close) Client 2 connects -- Factory instantiates Protocol class to handle communication (connection doesn't close) <time has passed until server decides it needs to send a plugin to one of the clients> Server sends plugin to Client 1
So how can that server send data to client 1 if client 1 hasn't caused an event (The server side causes a certain event it should send data to a selected client).
Define `event'. Is the initial connection not an event? If you have an open connection, the client doesn't have fart back through it every 5 seconds (by the semantics of most protocols) to keep it open or anything.
I understand that if a client sends data to the server I can than write back to the client using the dataReceived function within the Protocol instantiation.
Are you sure you understand? You're calling dataReceive to send data? If you're calling a method (that's what you meant by "function within the Protocol instantiation", I guess) with "receive" in the name, then you can only be very confused.
In this case once N number of agents have connected I want the server to push data to the clients without the Client writing to the server. Thanks again for the help.
So write back data to the client. That's all I can say until you describe what you've tried (w/ code) and why it failed (w/ a stacktrace) - vs. in pretty vague terms on essay on what you want to do and haven't even attempted.
-- \\\\\/\"/\\\\\\\\\\\ \\\\/ // //\/\\\\\\\ \\\/ \\// /\ \/\\\\ \\/ /\/ / /\/ /\ \\\ \/ / /\/ /\ /\\\ \\ / /\\\ /\\\ \\\\\/\ \/\\\\\/\\\\\/\\\\\\ d.p.s
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
<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.
participants (4)
-
Atilla -
Chris Dew -
David Welch -
Drew Smathers