Three way communication through connectors

Good gurus of the second day,

I am very familiar with basic socket programming and the IO :: Socket module, but I need to encode something now that I have not encountered before. This will be a three-tier application. The first level is an event loop that sends messages upstream when certain events occur. The second level is a mid-level server that (among other things) acts as a message repository. The third level is the cgi application, which will update the graphic display.

I am confused about how to configure the server to accept unidirectional connections from several clients on the one hand and two-way communication with the cgi application on the other. I can do any of these tasks separately, just not in the same script (for now). Does my question make sense? I would like to use the IO :: Socket module, but this is not a requirement. I do not ask for polished code, just advice on setting up the socket and how to communicate from one client to another through the server.

Also, does it make sense to have a cgi application requesting a server for new messages, or does the server push a new message up in relation to the cgi application? Graphic updates should be in real time.

Thanks in advance,

Daren

+4
source share
2 answers

You said that you already have a cycle of events in the first tier. In a sense, your second-level server should also organize some kind of event loop for asynchronous processing. There are many ways to encode it with perl, for example AnyEvent , POE , Event , to name just a few. In the end, they all use one of the OS components select , poll , epoll , kqueue (or their Windows equivalent). If you feel comfortable coding at a relatively low level, you can simply use the perl select built-in or, alternatively, its object-oriented analogue IO::Select .

Basically, you create two sockets for listening (you may need only one if the first level uses the same communication protocol as the third level to talk to your server), add it to the IO::Select object and make a selection on it. After connecting, you add the received sockets to the selected object. The select method IO::Select will provide you with a list of sockets ready to be read or written (I ignore the possibility of exceptions here). Of course, you have to keep track of your sockets to find out which one. In addition, the communication logic will be somewhat complicated, because you have to use non-blocking sockets.

As for the second part of your question, I'm a little confused about what you mean by “cgi” - whether it is a common gateway interface (ie server side web scripts) or is it short for “computer graphics”. In both cases, I think it makes sense to use a push server for your task. In the latter case, all that I would like to say. In the first case, I offer you google for "Comet" (as in "AJAX"). :-)

+5
source

In the standard CGI application, I don’t see how you can “click” data on them. To interact with the client, the data passes through the CGI / presentation level to the middle level in order to remain in the storage (or cache) of the session or on the backend for receiving in the database.

This, of course, if you do not have a thick application layer, which is the locus of caching and a kind of intermediate level in itself.

0
source

All Articles