requinix

You can call $this->close() or whatever to "close a connection". You cannot unset $this. I can't think of any reason why you should need to. If the calling code wants to destroy the object then it needs to do that (and by "destroy" I mean remove any reference it has and forget about the whole ordeal (however the object may be referenced somewhere else)).

Your form has method="get" but you are using $_POST. method=get goes with $_GET, method=post goes with $_POST.

//How can I validate that the received message length prefix matchs the length of the message so it doesn't get out of sync?...you can't. Because you're using that length to decide how long the message is. If the other end sends the wrong length then it's their fault, and you'll probably discover it when the json_decode() fails. It's pretty simple so yeah.

I would expect parseBuffer to look more like do { if have message length { if buffer is >=length long { get message as substr(buffer, 0, length) deal with message adjust buffer to substr(buffer, length) reset length } else { quit loop // wait for rest of message } } else { if buffer is >=4 long { get length as substr(buffer, 0, 4) and unpack adjust buffer to substr(buffer, 4) } else { quit loop // wait for rest of length } } } indefinitely // will keep going until buffer runs out

Showing calories in the first part and weight in the second doesn't make sense. Should be the same units for both: calories burned and remaining, or weight lost and remaining. Regardless, you need a percentage, and that requires having (if not showing) both numbers in the same units. Do you have the code at a point where you have two variables, one for the amount of s done so far and another for the amount of s remaining to be done?

The progress bar would be the number of calories burned so far compared against the total number of calories you estimate they need to burn, right? That's easy enough to do on a page so long as you can come up with those two numbers - really, a percentage. The only question for this part is what you want the progress bar to look like. Calculating the calories to burn is harder. You need to do some research about this because there is no simple conversion rate between calories and weight lost.

Oh, well then, use the title. The URL would look like my.php?channel=TV%20Channel%201 or ?channel=TV+Channel+1 (whichever you would rather have) by using http_build_query; use the PHP_QUERY_RFC3986 enc_type if you want %20s instead of the default plusses.

Import what? Settings? XML? Key? Did you explain what any of this is in another thread, or this is it?

But you don't have an ID to work with - just "TV Channel N", and whatever the URL is but you said that changes. If there aren't too many channels in that list then you could do something like hash the name: echo "myphp?channel=" . sprintf("%u", crc32("TV Channel 1")); // myphp?channel=3485320925then search the XML for the channel with a matching (by doing the same sprintf+crc32 on each one and comparing the numbers).

>attached >no attachment

I imagine that the job is being killed off when the shell exits. Don't do this anyways. Use cron to set up a regular job, even if that job runs every minute and doesn't do anything. Store the information needed (like the permalink) somewhere and have the cronjob scan for jobs and process them.

Aside from the few remaining functions in PHP which issue warnings in cases that don't need them, @ is fine if you are already accounting for potential problems being covered up; note that custom error handlers will still receive the warning, but with $errno=0. @$_POST["letmein"] != $foo !isset($_POST["letmein"]) || $_POST["letmein"] != $fooaccomplishes the same thing either way, but using @ lets you avoid the tedious isset() check. With PHP 7 you could swap the @ for a ?? ($_POST["letmein"] ?? "") != $foo

You can't. Not with the model you're using. You're talking about something that happens at runtime - unless you want to make a class for every single possible combination of features (spoiler: you don't) then that sort of behavior needs to be managed dynamically. As a first draft, interface ObjectFeature { public function __construct($object); } interface ObjectHasFeatures { public function addFeature($feature); public function getFeature($class); public function hasFeature($class); } trait HasFeatures { private $_hasfeatures_features = []; public function addFeature($class) { $this->_hasfeatures_features[$class] = new $class($this); } public function getFeature($class) { return $this->_hasfeatures_features[$class]; } public function hasFeature($class) { return isset($this->_hasfeatures_features[$class]); } } class Car implements ObjectHasFeatures { use HasFeatures; private $name; public function __construct($name) { $this->name = $name; } public function getName() { return $this->name; } } class FlyingFeature implements ObjectFeature { private $car; public function __construct($object) { assert($object instanceof Car); $this->car = $object; } public function fly() { echo "*{$this->car->getName()} starts flying*\n"; } } $car = new Car("Notion's Car"); $car->addFeature(FlyingFeature::class); $car->getFeature(FlyingFeature::class)->fly(); https://3v4l.org/Qmm0D

For a simple solution, keep your virtualhost conf files on the host machine (eg, vagrant/www/*.conf) and do something like Include /path/to/wherever/*.confin the Apache configuration. Then you can configure each virtualhost however you want, with whatever root you want.

Yeah, I was getting confused there for a bit. Anyway, I think kicken is talking about the $data->id. The clients (being the ones generating those IDs) would use a sequential number, and the easiest way to go about that would be with a static variable somewhere: static $id = 0; $message = [ "id" => ++$id, ... ];Really, though, the client can do whatever it wants as long as the ID is scalar (for use as array keys) and "guaranteed" to be unique during the lifetime of that particular message's request/response cycle.

Um, so, question, How are you coordinating these IDs across clients? Given that the server needs to know which ID corresponds to which client.

And these are the people companies will hire to replace us

Your solution does not match your description, which is probably why no one was able to get you the answer you wanted, but at least you figured it out eventually.

A for loop will work. If the code you wrote does not work and you want us to help then we need to see what you tried. Do you understand what those variables are supposed to mean? Being a programmer is not about following recipes. You have to actually know what you're doing. Think about what you're doing. These variables count how many times each die face was rolled, right? So why does your code think 6 has been rolled six times before it has even executed? If you think writing pseudocode is a kinetic exercise then you don't know what it means to write pseudocode.

$face = rand(1, 6); switch ($face) { case "1": echo $frequency1++; break; case "2": echo $frequency2++; break; case "3": echo $frequency3++; break; case "4": echo $frequency4++; break; case "5": echo $frequency5++; break; case "6": echo $frequency6++; break; default : echo "0"; }That is where you roll a die and track the result. Use a for loop to do that 5000 times. There's also a problem with your code: //Frequency of Die $frequency1 = 1; $frequency2 = 2; $frequency3 = 3; $frequency4 = 4; $frequency5 = 5; $frequency6 = 6; If those variables count the number of times each face was rolled then shouldn't they start at 0?

Ohhh, right, you have the ID you can use to track messages... yeah... Then that all works out.

Weed out any strings that don't match? Match an opening parentheses, use (?R)* for recursion, and match a closing parenthesis, then check that what you found was the entire string. If you want to weed out any parentheses that don't match then it depends how you want to report on what didn't match...

Okay, then "Client A, which is a super client,...". But what happens from there? Server recognizes it as a forwarded request, pulls the method and params out and sends it as a new request to whichever client, then that client responds normally... How does the server know to (repackage? and) forward it to the first client? It could assume clients are responding to requests in order, but that means blocking and you don't want that. So somehow the response from the receiving client must be tagged in such a way that the server recognizes it as a response to a forwarded request, which implies something in the original request so that the client knows it needs to tag its response... which is the sender/receiver target stuff I said.

Thread renamed from "How to implement handshake between client and server?" Reminds me of NAT or TCP/IP masquerading. My computer here at home has the address 10.1.1.5, which is a private network that nobody outside the network can send packets to. I'm able to be on the internet because my router performs IP masquerading on outbound packets, rewriting the packet such that when a response returns the router recognizes it as using masquerading and routing it back to my computer. With that said, your clients are already somehow able to identify other clients connected to the server - something which the internet cannot do. So you have two options: a) Masquerading. The super client sends a request to the server including which client to route to, the server uses masquerading to rewrite the request and send to the desired client as if it were normal communication, the client (potentially) replies like normal, then the server remembers the masquerading and sends the reply to the original client. That's probably more complicated than you need. b) Forwarding. When the server is not a direct recipient of a message, it acts as a somewhat dumb router (aka a switch) and simply forwards the message to whichever clients are requested. Super client A issues a request to client B, server routes it to client B, that responds knowing it goes to client A, and the server routes that one too. (b) is probably the best option here. It does add a requirement of knowing where a request/response needs to be routed to, added at the top-level object (which is how TCP/IP does it), but you could make that optional and default to being between the server and client. JSON-RPC doesn't give explicit support for that, but adding two new members would still be compatible with the spec - and there's no reason why you can't extend from it if you remain compatible (not to mention that it's your protocol).

...Sure? You're describing a general concept, and even searching for "application protocol" is going to get you too much information. Try thinking of existing mechanisms you know of that are similar (in scope, functionality, medium, whatever) then finding more information about how they work. Right. What I meant was that the method + parameters thing is like how SOAP works - it being an example of something you aren't using. Now it's a question of what message it's sending. The thing you described earlier really deals with a sender and receiver - it works for client-sender/server-receiver fine, but now the issue is whether it works for server-sender/client-receiver. And that depends on the messages being exchanged, which I'd guess would be like the former's.