By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,852 Members | 2,259 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,852 IT Pros & Developers. It's quick & easy.

perl socket listening server

P: 1
I want to set up a push-server system on my hosting provider. However I can't run java or install tomcat, so comet and dwr is out of the question.
The system should be able to run sort-of a real time "chat" so when a user sends a message it's instantly displayed to everyone else. Cannot use polling or 1-second refresh on the page as that will create MASSIVE mysql overhead if there are 1000-2000 users logged in (2000 mysql requests per second)

Here's a "solution" i have in mind:

set up a perl listening server with sockets. a php script connects to the socket and perl can now "push" to php which displays the results to users.

i want to set up for ability to expand (i.e. start with 20-30 users and ability to support 5000+users)

any help on how to set up the perl script would be appreciated. or if there are more elegant/simpler/more efficient solutions, i'd like to hear them too.

May 3 '10 #1
Share this Question
Share on Google+
1 Reply

P: 2
Google for "perl listen socket" for help on syntax and you will find something like the following:

If this were my project, I would do it on a Unix based OS where fork behaves well.

It could be as simple as a server process that is configured under inetd. That will allow the creation of the responders and can handle the processes. I have created applications like this that will handle hundreds of connections. To be able to handle 5000+ means that the computer system will be required to have enough resources to handle the processes.

If you do not want to run under inetd, then you are responsible for creating its functionality, namely listening, then forking off processes to handle the connection.

You want your listener process to be very light. It should only be responsible for listening to the incoming connections (some of which can be buffered by the network layers, but there is a limit) and then hand off (really "fork" another process) the actual responsibility of responding to each your users. If you have the processing within the listener, it will be spending time processing and may miss incoming requests.

A simple application of sending messages is included in the web page I noted at the top.

Although written in C, not Perl (easily adaptable), here is a web page (directory) with tcpserver.c, tcpclient.c which demonstrates the principles of a forking process which listens to sockets.

May 18 '10 #2

Post your reply

Sign in to post your reply or Sign up for a free account.