Find the answer to your Linux question:
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 27
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Linux User IsaacKuo's Avatar
    Join Date
    Feb 2005
    Location
    Baton Rouge, LA, USA
    Posts
    406

    If you want the server to know that "key p has been pressed", you need three basic things:

    1) You need to write javascript method in the web page that reacts to an "onkeypress" event. This javascript method will be executed by the client web browser, strictly on the client computing device.

    2) This javascript method must include something which makes some communication with the server. The traditional AJAX method of doing this is to send an HTTP request with some data encoded in a POST, or the data might be encoded in the URL itself.

    3) Some code on the server to react to this communication. The traditional AJAX method is a PHP script or a CGI script. These traditional methods tend to involve a huge amount of overhead and are not very efficient. Each piece of data sent involves negotiating a new TCP connection, encapsulating the data within a bulky HTTP request, spinning up a new PHP or CGI thread, and interpreting the data while using some sort of shared multi-thread safe temporary data store to deal with continued context.

    Unless you have some serious reason to want to use CGI and traditional HTTP requests, a far more efficient alternative would be to use WebSockets or even write your own custom TCP based daemon. WebSockets are basically a plain old TCP connection--two way and persistent--encapsulated in a negotiation standard similar to HTTP. This negotiation standard makes WebSockets generally more firewall and router friendly than arbitrary custom TCP connections.

    With a two way and persistent connection, you would have javascript code on the web page open up a connection from the client to your server right when the page loads. Then, the onkeypress method simply sends a tiny bit of data down this connection when the user presses a key. On the server side, depending on the implementation you might have a single daemon thread handling all incoming connections or there could be a different thread for each connection. Either way, you have some code waiting to consume incoming data, which it then deals with.

    See, with traditional HTTP requests, the connection is NOT persistent. The protocol is very strict, and meant to be temporary. The client sends some data, and then the server sends some data back, and then the connection is closed. End of story. With WebSockets or custom TCP connections, the connection may be left open for any length of time, and both sides may freely send data at any time, in any order.
    Isaac Kuo, ICQ 29055726 or Yahoo mechdan

  2. #12
    I knew pretty much all of that, but thanks, Isaac How old is WebSockets, which year did Firefox first get it? I don't think it would be safe to use, specially in this neck 'o the woods. Though of course, we can't remain outdated forever!

    If WebSockets were NOT used, but simply AJAX instead, can PHP be used for writing the server side, i.e. daemon?

  3. #13
    Linux User IsaacKuo's Avatar
    Join Date
    Feb 2005
    Location
    Baton Rouge, LA, USA
    Posts
    406
    Quote Originally Posted by resetreset View Post
    I knew pretty much all of that, but thanks, Isaac How old is WebSockets, which year did Firefox first get it? I don't think it would be safe to use, specially in this neck 'o the woods. Though of course, we can't remain outdated forever!

    If WebSockets were NOT used, but simply AJAX instead, can PHP be used for writing the server side, i.e. daemon?
    As I noted, traditional AJAX would use either a PHP script or a CGI script on the server side. In neither case is this a daemon, because it is only invoked upon an HTTP request and it dies upon completing the request. The relevant daemon would be Apache, or some other web server, waiting for incoming HTTP requests.
    Isaac Kuo, ICQ 29055726 or Yahoo mechdan

  4. $spacer_open
    $spacer_close
  5. #14
    ....so the PHP script would have to "attach" itself to Apache?

  6. #15
    Linux User IsaacKuo's Avatar
    Join Date
    Feb 2005
    Location
    Baton Rouge, LA, USA
    Posts
    406
    Quote Originally Posted by resetreset View Post
    ....so the PHP script would have to "attach" itself to Apache?
    There isn't anything special that you have to do with the PHP script. It just sits inside /var/www just like any other web page. Usually, Apache is configured to run PHP scripts by default. It uses a module called mod_php to do this. With this module active, Apache will handle any HTTP request for a file ending in .php by executing the php script and returning the output of the php script.

    If mod_php is not installed or configured to be inactive, Apache would simply handle any HTTP request for a file ending in .php by returning the contents of that file. (This is the way Apache handles requests for most files, such as .jpg files or .html files.)
    Isaac Kuo, ICQ 29055726 or Yahoo mechdan

  7. #16
    ...so, would this be how it works for eg. a chat daemon? I realise that in a chat program, the user would have to press enter to send the text to the server, but I'm assuming that that won't make a difference to the server side, if I get hold of the text *before the user has pressed Enter*?

    If it's not too much trouble, could you point me to the PHP code for this? Or just tell me what to Google for....?

    Out of curiosity, does Apache always need mod_php in order to process .php files?

  8. #17
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    1,953
    There are three ways to process PHP with Apache - mod_php which is loaded and handles PHP directly, PHP-FPM which or mod_fcgid which both use FastCGI.

    XMPP - Wikipedia, the free encyclopedia
    Libraries ? The XMPP Standards Foundation

  9. #18
    Er greg, I'm not writing a chat program, that's just an example I used.

    I wanted to know that about PHP because I myself *use* a site where, it has happened, that when the server was under heavy load (the site was slow), instead of getting the page, I saw SQL statements on my screen! I just wanted to understand whether this kind of thing is even possible here - note that I have no clue about the backend of this site - it may well have been using Microsoft!

    What exactly is "FastCGI"?

  10. #19
    Linux User IsaacKuo's Avatar
    Join Date
    Feb 2005
    Location
    Baton Rouge, LA, USA
    Posts
    406
    Quote Originally Posted by resetreset View Post
    ...so, would this be how it works for eg. a chat daemon? I realise that in a chat program, the user would have to press enter to send the text to the server, but I'm assuming that that won't make a difference to the server side, if I get hold of the text *before the user has pressed Enter*?
    What is your end goal, here? You don't seem to have much grasp of the issues involved. Please understand I'm not insulting your intelligence here--the issues involved are not obvious!

    It sounds like you want to implement a chat server, which reacts to and broadcasts each keypress as it happens. On the one hand, it is easy enough to simply have the client send each keypress rather than a line at a time. On the other hand, if you do this it will not work how you expect and it will be obscenely inefficient unless you use WebSockets or custom TCP or some equivalent.

    There are two reasons for this, neither of which is obvious to a newbie:

    1) HTTP requests involve a lot of overhead, if the payload is just a single character of data.

    and

    2) HTTP requests are not guaranteed to arrive in the same order in which they are sent. This means that if the user types in H E L L O it might arrive L O L E H. For normal chat program examples, this isn't so much of a problem. It takes many seconds for a person to type in a line, and they'll intuitively wait for the previous line to show up before typing in the next one. But individual keypresses can easily bunch up during a hiccup in an internet connection, resulting in a bunch of requests that come in at once--in random order.

    Any sane implementation of what you're thinking of will do something complex to deal with data arriving in the wrong order and/or failing to arrive...along with requests to resend data...basically re-implementing things that TCP or WebSockets already do...and for what? Just to avoid using WebSockets? (Actually, yes. There is a lot of older server code which couldn't count on WebSockets being available, so they hacked really awful ugly solutions to do something as seemingly simple as realtime chat.)
    If it's not too much trouble, could you point me to the PHP code for this? Or just tell me what to Google for....?
    You can search for "PHP Chat example", but I think you'll only see examples where a single line is sent at a time. You can modify the client to only send one character at a time, but be prepared for weird behavior and extremely awful performance. It is possible to fix the weird behavior and improve performance to acceptable levels, but this involves complex code that is far beyond the scope of a beginner's example program.

    ...Or, you could use a tool which is far more suited to the task, such as WebSockets.

    But I'm still just assuming what your task is, because you don't explain exactly what your goal is. If you explain your goal, then it will be easier to figure out what solution is sensible.
    Isaac Kuo, ICQ 29055726 or Yahoo mechdan

  11. #20
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    1,953
    Apache isn't really designed for WebSockets for anything other then a very limited use. If you are going to use WebSockets you should install a server optimized for that purpose. It's also worth taking into account that WebSockets in older browsers are likely not implemented so something along the lines of long polling is done to approximate the effect.

    IMO the advantage of WebSockets is primarily that real time (or pseudo real time) server side notifications are possible with them but if everything is being initiated from the client side they are the wrong model and there is no efficiency gain over persistent HTTP (and a sensible architecture) and a greatly increased cost server side.

    FastCGI is a protocol that replaced CGI. The biggest difference is that instead of starting a process for every request processes are persisted.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •