requinix

On how to do... what? There are multiple options here that you should do some research on and think about before jumping right into the code.

Either change the link so that it takes them to the purchase page, or make the download link redirect the user (with or without a warning) to the purchase page. When they buy it, redirect them back to the initial page they were on - the one with the link they clicked. If it's not obvious, you never link to the actual music file. Downloads should always be handled by a PHP script which authenticates the user before directly outputting the music file. Really the music itself shouldn't be located anywhere on your server in a place that someone could access it over the web.

Step 3: copy the data. Where's the confusion?

Referring to the last line: $streamStatus = $obj->isConnected?'true':'false';

As the docs say, brpoplpush - which you can read as a "b"locking "r"ight "pop" and "l"eft "push" - deals with two lists, and moves one element from one to the other. If all you need is a simple queue with blocking then do lpush+brpop or rpush+blpop (whichever "direction" makes most sense to you).

Anecdotally and without any sort of source to back me up, you shouldn't do an indefinite timeout on a blocking function. I think that's from personal experience. Do a "long" timeout of less than a minute, then worst case your loop just jumps back to the start and it starts blocking again immediately.

You lost the CURLOPT_RETURNTRANSFER option from your first post. Need that.

Measure the time yourself. $start = time(); whatever loop { $remaining = $limit - (time() - $start); blocking function with timeout of $remaining if possible if function timed out or time() > $start + $limit then die }

The formatting doesn't matter - those two JSON samples are equivalent. $obj is an object by default. You can work with that just fine. It doesn't have to be an array. But if you really want an array then check the documentation that Barand linked to.

Are you running PHP from the same machine that you tried with the browser? A timeout suggests the connection is blocked, like by a firewall.

Then rather than watching a file try message queues: process that receives the AJAX requests sends a message to a queue while the processes that talk to clients wait (again, with blocking) for a message to arrive on their particular queue. Software like Redis and (IIRC) Memcached can also do blocking queues, if you have anything like that already in place. If the data is small then the message could contain it, otherwise all it has to do is act as a signal that the receiving process needs to check the database. Point is to avoid polling.

The client script has a couple =s that should be ==s. If you're polling a file then you should look into using inotify: you can have your script "watch" for particular events on a file, with blocking so you don't have to poll so frequently.

I'd put my vote for the 5-minute polling thing. Since a 5 minute delay is acceptable, go for that to have things working (you could even have it run every 1 minute), then afterwards you can think about the next version.

Same words, multiple meanings. Computer A connecting to computer B could mean that A wants something from B, but that isn't always the case. The networking layer is only concerned about establishing connections, so it doesn't matter who wants what from whom but rather who is going out to connect to the other. As such "client" is connecting and "server" is receiving the connection. In higher layers than that, such as with HTTP or generic applications, the two terms still mean the same thing - they just have added connotations, such as "the client requests a URI from a server". Client connects, server is connected to, and there may be more to it than that. Correct! The operating system running on the server can't know whether a connection to port 80 should go to one application or another, thus the port can only be in use ("bound") by one at a time. A few years ago Skype was using port 8080 (I think?) by default, however some WAMP/XAMPP/et al. bundles had default configurations to use port 8080 as well, and that caused many new developers to ask why they couldn't start up Apache when they had Skype running. It's both: it has code to deal with managing connections and it has the ability to act as an HTTP client. Client connects, server is connected to, maybe other stuff too. ComputerLocal can connect to ComputerRemote with no problem so that's fine. However if they don't want to change the firewall (a stance I agree with) then the only way to get a connection between Local and Remote is if Local initiates. This is the standard "polling" approach: if A cannot inform B of new information then B has to periodically ask A if there is anything. Yup. Yeah, but your hands are tied. It doesn't really have to "wait" to send data. You can follow the normal HTTP approach here: Local connects, sends a request for updated information, Remote responds. Maybe. As far as I'm concerned it comes down to one question: How quickly does ComputerLocal need to know about new information after ComputerRemote has learned about it? Immediately? Within a few minutes? Sometime that day?

Oh. I didn't think to mention one pretty big drawback with using such long connections: there's only a finite number of connections that a server can maintain, so this solution does not work for a "large" number of clients. I didn't get the impression that was the case so maybe that's why I didn't remember it. You're going to need to start adopting the proper terminology lest people be confused about what you're saying and what you may know about what you're saying. "Response" is an HTTP thing that may be relevant to your application but isn't part of the general networking paradigm. A server does a listen/accept loop: it listens for a new connection, accepts the new connection (which involves negotiating a new port so the original isn't tied up for long), does whatever it is supposed to do (which almost always involves handing the connection to a different process so the main server one can remain focused on accepting connections), and repeats. Uh no, it's not the same. The docs for stream_socket_server() even say that you need to then call stream_socket_accept(). s_s_s() basically wraps the "bind" call while s_s_a() wraps the "listen" and "accept" calls. Not a whole lot, actually. Check out the examples. Answered earlier. That's up to your application. There is no automatic reconnect at this low of a level. Sounds like you're confusing the client and server. The stream functions help, but if you want more then you'll probably have to find a third-party library for it. Personally, I'd just do it myself: beyond the initial learning experience there's not too much code involved. Like I said, check the examples. Maybe whip up a couple scripts to prototype the client/server communication process and run them on your own computer.

Ask your employer what they consider you? I mean it's just a title, it's not like some sort of contract. I called myself the CTO at my last job simply because I was the only IT person there (at a small company).

For clarification, exactly what does mean?

To be clear, a "stream" is what PHP calls its abstract representation of various things - mostly used with file handles, but it can be used with sockets too. They have a set of functions to operate on streams in a more-or-less general fashion regardless of the underlying entity. "Sockets" (BSD sockets at least) is the networking concept available in pretty much every language, where you deal with TCP/IP and connections and such. They have their own set of functions whose names tend to borrow from the C versions, and documentation for how to use them in one language tends to port over fairly well to other languages. So, Yes: a socket opened between two hosts that tries to stay open for pretty much ever. Realistically the A host would need to be able to reestablish the connection if/when it drops for whatever reasons. Yes. In networking terminology, the "client" is the one doing the connecting and the "server" is the one being connected to. If it weren't for the fact that hardware allows for not needing to do that, yes. What you actually do is called a "select", which blocks (the function call doesn't return) until something about the connection changes - such as there being incoming data or the connection goes down. With an optional timeout, if you want to be able to do other stuff while waiting. Unless poorly configured, firewalls allow traffic to go both ways through previously-established connections. When people talk about blocking stuff with the firewall it really means blocking the initial connection attempt. Read up on TCP/IP networking (to know about what's going on) and BSD sockets (to know about how to do stuff in code).

Your options are basically a) A polls B for information b) A establishes a persistent connection to B and waits for activity c) A opens up a port on the firewall and lets B connect The stream functions are a bit higher-level than the raw socket functions so I suggest you try to use them.

Print design = someone who designs for print Web design = someone who designs for the web If you can do both then call yourself a "Web Designer" when talking about the web and a "Print Designer" (I guess?) when talking about print.

Dude. Punctuation and complete sentences. plzkthx It's not entirely clear what they're saying, but what I believe they're trying to say is: You need to make a GET request to a particular URL. You've done one like that in step 1 already. This time the URL is not fixed: it starts with "https://test.oppwa.com/" like before but the rest of it was passed in the request URL to your page as "resourcePath". So the proper URL is "https://test.oppwa.com/" . $_GET["resourcePath"]Add on the authentication stuff like before, do a request like before, and the result will be... something. I don't know that part.

What's your code?

You aren't really saving yourself much: still typing out the basic key => value stuff for each element you want. A sort of "array_choose" function would be nice to have built-into PHP. I wouldn't implement it in userland just for this one purpose, though. /** * Extract a subset of an array * * @param array $array Source array * @param array|scalar $key An array of keys, or the first key * @param scalar ... Additional keys if $key is not an array * @return array */ function array_choose(array $array, ...$keys) { $return = array(); foreach (isset($keys[0]) && is_array($keys[0]) ? $keys[0] : $keys as $key) { if (array_key_exists($array, $key)) { $return[$key] = $array[$key]; } } return $return; }

I'd either do that or the obvious solution, mostly depending on whether I remembered about array_intersect_key at the time.

By the way, in case you were considering it: Don't indicate whether the username does not exist vs. it does and the password is wrong. It reveals information an attacker could use. Use the same error message for both - ideally a single check in code like if (no matching row || password hash does not match) {