Php-Flash communication over sockets

[Mixo123]

Good time of the day, dear developers!

 

I am not any kind of network programming pro, but it happened that I have faced necessity to develop socket-server on php (no way for using Java) for flash multiplayer browser-game (standard features like locations, team battles, etc).

---

The main problem is that TCP is point-to-point protocol and it completely occupies given port.

 

Of course it is possible to create some kind of queue, which will manage connections to the socket, but this solution doesn't seems to be the fittest one.

 

It seems to me that using interval of "fair" ports (from 2000 to 2200, for example) is more fitting solution, because one request may take a lot of time to execute and players won't be happy to wait in queue.

 

But how can I implement this "port inteval" strategy? The solutions that I see are:

• 
  launcing php-script per every port (he-he, 2 hundreds of launched scripts!);
   
  
• 
  somehow forking the initial process to new processes (2 hundreds of processed? Not nice too), one for every port;
   
  
• additional while-loop, which listens all the ports (looks very bad);
  

 

But somehow I don't like any of them, or at least don't know how to implement them in the best possible way.

 

What is the best existing strategy to handle multiple requests from multiple users per time unit without delays, and how to implement this strategy in php? We have our own Debian-server, so it is possible to use any required php extensions.

 

Any advice about development, planning and implementation of such kind of systems is highlhy appreciated.

 

Thank You!

[Mixo123]

Edit 1: By the way, I've forgotten to mention some extra details.

 

For example, if we are trying to develop chat application, we need some sort of fixed (I mean persistent) connections for each user. For example, we have 80 users in chat, and then one of them posted a message, which server tries to handle and send to all other connected users, also putting an entry to the history file or something like that.

 

In this situation polling server for new messages every 10 seconds from each of 80 users is craziness, so the need in persistent connection gets obvious. But I don't know what is the best way to implement something like this, considering that not all requests are handled instanlty.

[Daniel0]

The main problem is that TCP is point-to-point protocol and it completely occupies given port.

 

Of course it is possible to create some kind of queue, which will manage connections to the socket, but this solution doesn't seems to be the fittest one.

 

It seems to be working quite fine for virtually all other services...

[Mixo123]

Hmm, may be. But the problem is that not all requests are handled quickly - it is possible, for example, that single request will be executed for 1 second, and may have queued after it 10 other requests from different users.

Will the last user wait 10 seconds for his request to be served? I'm not sure.

 

So that is exactly what my problem is.

 

As I understood, you recommend me to create an array for storing all current connections, and to bind all them to single socket (therefore to single port), and then to organize their work by loops (for example, if onMessage event gets fired up by posted message, the event's handler loops throught the connections array and sends to all it's elements new message)?

 

Is that really the best known solution in terms of perfomance?

[Daniel0]

The typical solution those kind of locking problems would be concurrency/multithreading. PHP supports process forking using pcntl_fork. It only works on Unix based systems, which might be a problem for you.

[Mixo123]

No, environment is not problem - this daemon will be launched only on Linux-powered server (I think it'll be something like Debian or CentOS). So I'd like to listen how to use this feature.

 

Forking? As I understood, I need to fork the initial process for every port in the given interval, create a new socket for every new clild, bind it to the next port, and finally to save new socket into some kind of a global array (in the parent?), which I will later use for broadcasting.

 

For example, 100 child processes, each listening single socket from the given 100-port interval and using an array with all existing connections, which is located in the parent?

 

Am I right? Correct me, if not.

 

p.s.: is it Ok, that now we will probably have some new forking burdens (I mean, 100 processes... Although, there might be need in benchmarking to check what is faster)?

[Daniel0]

Well, the basic idea would be to have an infinite loop running that keeps listening for incoming connections. Each time someone connects, you fork an additional process allowing the client to do whatever your client supposed to do. Then just you exit the forked process when the client is done.

 

I would just drop the entire "multiple ports" thing altogether.