You can push to the client with sockets. Every time something comes from the server with a 0 byte terminating it the XMLSocket object gets an onData event.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, November 04, 2005 3:16 PM To: [email protected] Subject: Re: [Flashcoders] Need advice on XMLSocket architecture can your client afford Flash communication server, it has true push technology to the flash application but its not cheap licensing. Can you really push using an XMLSocket, I thought it was still request/response and not "listen" from the flash runtime unless you use rmtp and net connection. red5 would meet your needs but won't be GA for a while.. Grant ----- Original Message ----- From: Jim Phelan [EMAIL PROTECTED] To: 'Flashcoders mailing list' [email protected] Sent: 11/4/05 3:09 PM Subject: RE: [Flashcoders] Need advice on XMLSocket architecture > Tracy, > > I think you're going to find the latter of your two approaches to be more > efficient and quite easy to accomplish, especially the server will be > authored in .NET. If you're using the term port to refer to the actual > socket, then you'll find that handling multiple clients concurrently is > fairly easy to achieve without needing to filter results on the client side. > > The main issues you're going to find with this sort of thing (network / > tunneling issues, thread management) will probably be non-existent in a > controlled environment with 100 clients. > > I see the very basic architecture as something like this: > > Flash client xml/ascii serialization/deserialization layer .net > socket server xml/ascii serialization/deserialization layer system > internals or .net remoting to the service aggregator / whatever > > The other option in which you could avoid writing a server would be to poll > (even though it seems yucky) very quickly. Probably not such a huge burden > if you're on a lan and use flash remoting. > > Jim > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tracy Spratt > Sent: Friday, November 04, 2005 2:44 PM > To: [email protected] > Subject: [Flashcoders] Need advice on XMLSocket architecture > > Hello, I'm a regular on the flexcoders list, where it was suggested > that I ask my question over here. Any advice will be welcome! > > I have 100 fixed, identifiable clients running a Flex 1.5 app on an > intranet. A Dot.Net integration tier maintains individual states for > each client. The integration tier talks asynchronously to third party > apps over async tcp sockets and even mail transport. I had planned on a > leisurely polling setup to get the clients updated with changes in > state, but I now have a requirement for an update with minimum latency. > > The messaging between clients and server is very low frequency (a few > clients updated per minute) and very low message size (a few k per > update). > > I am now looking at a true "push" connection using XMLSockets. I see > two approaches: > > On would be to have a separate port connection for each client with each > client only getting their messages, the other would be a single port, > where all clients would get all messages, and ignore those that were not > theirs. > > In my case performance, reliability and simplicity are most important, > and scalability not so much an issue. > > Any suggestions, experiences, resources would be appreciated!! > > Tracy > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
