[Sgdc] PHP

Jordan Scales scalesjordan at gmail.com
Mon Sep 17 13:28:53 EDT 2012


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.  
> 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.
> Client computer (call it CC) sends a browser HTML request to WS.  (The WS prompts for authentication.  CC provides it.)
> 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/afae3c38/attachment.html>


More information about the SGDC mailing list