0

I have a flash app running on 1200 machines on a local network. Currently, the app polls the php server every 10 seconds, and is returned a 14 byte string with the state. If the state is new, the app changes mode and gets new data from the server.

1200 machines polling every 10 seconds to pick up ~8 state changes per day seems like an awful lot of network traffic for this.

There is other traffic on the network (streaming video, web surfing etc). When the network load gets high, some of the machines loose the ability to communicate with the server and hang. When I run 400 machines I don't run into this problem. Looks like a scalability problem.

What would you recommend for lightweight communication between server and 1200 clients? Remoting with AMFast? XML Sockets? Something else entirely?

Thanks very much!

Sparky1
  • 3,335
  • 6
  • 26
  • 29
  • Possible duplicate of http://stackoverflow.com/questions/1300755/persistent-connections-between-flash-client-and-java-server – Madbreaks Mar 09 '12 at 18:25
  • The first thing you should ask yourself is: if the state changes 8 times a day, is it really necessary to have an update instantly after 10 seconds? If so, there's also another possibility: push the state of the server to an external server (a simple `changed = true;`) and let your clients poll the external source until a change actually occurs. – weltraumpirat Mar 09 '12 at 18:45
  • "and let your clients poll the external source until a change actually occurs." -- This is what I'm doing now. The 10 second polling interval is needed. When the user buys something I need to deliver it when the purchase completes. – Sparky1 Mar 09 '12 at 18:52
  • But from your description, the server that holds the change status and the server that issues the delivery message are one and the same, or are they not? My point is that you can redirect the server load to a proxy somewhere outside of you local network to take stress away from the server that has the actual delivery status. – weltraumpirat Mar 09 '12 at 20:40
  • Ah. Good point. I see where you were going now. Thanks – Sparky1 Mar 09 '12 at 20:56

2 Answers2

1

Socket communication, and having the server send a message to the clients when the state changes, instead of the clients polling the server, seems like the way to go here. Almost a textbook example for sockets vs polling, I would say.

In applications for public web, socket communication in Flash can sometimes be troublesome because of firewall settings and using other ports than 80 and so on, but in your internal system, it should work fine.

Lars Blåsjö
  • 6,118
  • 2
  • 19
  • 23
  • Okay.. but if I have 1200 clients it seems I would need a web server capable of handling 1200 concurrent tcp connections. It seems like I'm just trading one kind of scalability problem for another. Am I missing something? – Sparky1 Mar 20 '12 at 23:27
0

Do you need the state to be a 14 Byte string (14 Bytes is 112-bits which would support 5.19 x 10^33 different status'), are there really that many states that you need to communicate?

How many states do you need to convey?

Steve
  • 340
  • 4
  • 16
  • Those 14 bytes amount for about a meg of traffic total - that should't be too much of a problem on a local network. The overhead of establishing 72000 connections per minute to a single server is what's really slowing you down. – weltraumpirat Mar 09 '12 at 18:49