[Sgdc] PHP

Dylan Hutchison dhutchis at stevens.edu
Mon Sep 17 14:55:13 EDT 2012

Ah ha! There's an idea.  I could use the _SESSION associative array to
store information about the current client connection / session (including
the socket connection) and perhaps use the filesystem as a global registry
accessible across all sessions to put information I need accessible to
every session (such as the connection information to the DS).  I'll do more
research later and see if this is workable.

Yes, I will have to wrap the client's communication in HTTP POSTS, but
theoretically it's possible.  I'll need to look into your suggestions of
WebSockets with PHP more to see the details.

True, this is a hack, but it will be pretty cool if it works.  By the way,
the CS web server does run Apache.  Good guess!

@Jordan: Is there any component you're referring to as missing when you say
"too weak a foundation"?  Assuming I can make some function to
automatically wrap/unwrap packets from an HTTP POST layer, it could be
possible to get decent performance.  Ok, so real time video chatting is
probably a bit of a stretch, but who knows...

@SGDC: Sorry for spamming you all; forgot to remove the maillist off the
reply all.  I'll keep future communication between those who responded.

Thanks again for your help so far.  I'll let you know what I can find.

--Dylan Hutchison

On Mon, Sep 17, 2012 at 1:28 PM, Jordan Scales <scalesjordan at gmail.com>wrote:

> You'll want to use WebSockets. However, I don't see PHP as a good
> candidate for a real-time web communications. I guess since you need to
> operate within what the servers "allow" you to do, you're stuck with it.
> But everything you're saying here has already been done in the form of web
> sockets. As far as their application with PHP goes, Tyler's better-suited
> to answer that question. I've worked a bit with WS+Node, but never PHP.
> Otherwise you'll need this series of transactions stateful, with some
> session variable wizardry (which seems like the road you're heading down
> now), but that seems far too weak of a foundation to serve as a proxy.
> /$.02
> Jordan
> On Sep 17, 2012, at 12:59 PM, Dylan Hutchison <dhutchis at stevens.edu>
> wrote:
> Hi there Tyler, Christopher and Michael,
> Thanks a lot for responding so quickly!  I've coded only perhaps 30 lines
> of PHP i my life, so your advice will be great to determine how feasible
> this is.  I attached a picture with the traditional PHP setup on top and my
> idea on the bottom.
> In the standard PHP web server paradigm, the browser makes a connection,
> the PHP server runs the PHP script of the site which generates HTML output,
> and the web server sends the HTML response to the client browser.  The
> interaction is one-shot; there's no opportunity for continued data transfer
> / intreraction (whether started by the browser to the server or started by
> the server to the browser) in the same php session.  The browser could,
> say, reload the page, but that would run the php script again in an
> independent session.  *Key goal*: continuous, asynchronous two-way data
> transfer between the browser and server in the same run of the php script.
> Idea 1: if it's possible to use some kind of server-side static variables
> in the sens that I can store data and use/access it between php sessions,
> this would help a great deal.
> Idea 2: AJAX exists for the browser to send data to the server and get a
> response back asynchronously without reloading the page.  Likewise, HTML 5
> Server-Side events exist for the server to send data to the browser
> asynchronously (assuming browser support).  Can I leverage these two
> technologies here with php?
> Use case: did you know that any student can host files on their linux lab
> account accessible to the outside world?  You just need to create a
> public_html folder in your home directory and put in HTML or PHP files in
> there.  Check this out: http://www.cs.stevens.edu/~dhutchis/tb.php
> So my idea is to allow any student to host their own server of any type
> (imagine Vent, Minecraft, regular file server, streaming video, you name
> it) by using the PHP hosting capability of the CS web server as a proxy.
>    1. Desktop server on campus (call it DS) connects to /blah.php (call
>    it WS=webserver), and authenticates.  The PHP server stores the IP address
>    and port of the DS that the DS has open for incoming connections.
>    2. Client computer (call it CC) sends a browser HTML request to WS.
>     (The WS prompts for authentication.  CC provides it.)
>    3. The WS opens a TCP/IP socket connection to the original DS (whose
>    connection information it retained) and forwards data from the CC to the
>    DS.  Similarly, it forwards data from the DS sent back to the WS to the CC
>    (assume the WS can distinguish what data is intended for what CC).  Thus,
>    the WS becomes a proxy.
> Step 3 needs to be accomplished using forks, execs, more socket connection
> opening, cookies, local storage, ... whatever technology/technique it takes
> so that it can maintain that open socket connection to the DS for the
> duration that the CC wants to talk.
> Alternative 1: Use UDP instead of TCP.  Then it might be ok to close a
> socket connection and open another one; not sure. I'd like to avoid this if
> possible.
> Alternative 2: Have the WS open 2 sockets; 1 to the DS and another to the
> CC, providing the CC provides information about a port it has open and
> listening for incoming connections.  This may work well if the WS can fork
> up a new process which handles the 2 sockets and doesn't end/die until the
> CC and DS are done indirectly talking.  This may make the proposal much
> easier, but it's still be nice to avoid because it requires the CC have an
> open port.  We should ideally use the connection the CC makes when it sends
> a browser request to the WS.
> So let me know what you think, whether this sounds stupid or not.  I know
> you guys have your own things to do, but if we can determine that such a
> setup is possible, I will learn the PHP to do it (hopefully starting at
> resources you'll point me toward).  Thanks a bunch and I'm looking forward
> to seeing what you think.
> Regards,
> Dylan Hutchison
> On Mon, Sep 17, 2012 at 9:34 AM, Tyler Romeo <tylerromeo at gmail.com> wrote:
>> Hey,
>> Feel free to shoot me an email. PHP is one of my primary development
>> languages.
>> *--*
>> *Tyler Romeo*
>> Stevens Institute of Technology, Class of 2015
>> Major in Computer Science
>> www.whizkidztech.com | tylerromeo at gmail.com
>> On Mon, Sep 17, 2012 at 7:21 AM, Dylan Hutchison <dhutchis at stevens.edu>wrote:
>>> Hey folks,
>>> Are any of you PHP gurus out there, or do you happen to know someone
>>> with a wide knowledge of PHP?  I have an idea for hosting a server in the
>>> Stevens network accessible from outside the network involving PHP; I would
>>> love to bounce it off you and see if it's plausible.  If it works, it could
>>> be really useful for the Stevens campus.  Shoot me an email if you know
>>> some PHP or are interested.
>>> Thanks,
>>> Dylan Hutchison
>>> _______________________________________________
>>> SGDC mailing list
>>> SGDC at lists.stevens.edu
>>> https://lists.stevens.edu/cgi-bin/mailman/listinfo/sgdc
> <all.jpg>_______________________________________________
> SGDC mailing list
> SGDC at lists.stevens.edu
> https://lists.stevens.edu/cgi-bin/mailman/listinfo/sgdc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/sgdc/attachments/20120917/e40b7e9e/attachment-0001.html>

More information about the SGDC mailing list