requinix

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.

Oh, you don't want just the one result? You want all of them? SELECT * FROM table WHERE ddate I'd really have expected you to try that by now, though.

You only need the first URL to have that query string - it tells XDebug to begin the debugging session. If you lose the query string after, that's fine (and it's expected) and your debugging session will continue. So jump between pages to your heart's content.

Did you look at the query I wrote? I don't think you did, because if you had then you would know it only returns one result. And if it wasn't clear, there is a bit in the middle you need to do by yourself.

If you moved done, valid, and file into the visitas table then rel_visitas_utilizador would not be needed anymore.

Okay, so it's a 1-1 relationship then. Since there are only a couple columns in that table, and you know that those columns will have values, I would move them into the visitas table. It's not an important change to make, but it does reduce complexity. And I think that is the only change I would make.

If you think about it that way, it's straightforward: find all the rows that aren't too far into the future, sort them by the date in descending order (latest first), and pick the first one. SELECT whatever FROM table WHERE date is no more than 3 days in the future ORDER BY date DESC LIMIT 1

Right, but if your question is what to do regarding the schema, then first you need to understand the application. I see that it's 1-N now but I'm wondering whether that is the correct relationship.

What you described sounds like the teacher creates a study visit (new row in visitas) for every time they want a study visit. This one visitas row then gets a rel_visitas_utilizador row for approval by a manager. Does that mean there is a one-to-one relationship between visitas and rel_visitas_utilizador? One row in each table matches up with only one row in the other.

So would it be accurate to describe that as wanting the latest date you have available that is no more than 3 days in the future?

That's not really a "handshake". Like in real life, handshakes are used after the initial connection is made to identify both sides to each other and make sure they're all speaking the same language. For you, a handshake would do something like exchange protocol versions to negotiate which one to use - client supports 1,2,3, server supports 2,3,4, best version is 3. Speaking of, protocol is what you're looking at here. This version of the protocol - Exchanges JSON - Sends a request in the form {jsonrpc: 2, method: string, params: {...}, id: identifier} - Sends a response in the form {jsonrpc: 2, result: whatever, id: same identifier} Assuming it fulfills the needs of the application (eg, params being a keyed object instead of an array is up to you) that's a reasonable protocol. "Requirement"? "Protocol" may be the term you're looking for. It varies based on the application, transmission medium, data requirements... What you have there is actually like a JSON version of SOAP. Server making the connection doesn't make sense with your description. The client connects to the server to perform a task, great. The server connects to the client to... what?

Do you have both of those RewriteRules running at the same time? Which one is listed first? And "doesn't work" is meaningless. Means nothing. Unhelpful. How does it not work?

Notices and warnings are not fatal, but if you turn them into exceptions then they won't be. Go ahead and do that if you want in a development environment in order to find potential bugs, but don't do it in production - you don't want some random fluke somewhere to take down your site.

That URL would rewrite to /index.php?Page=bale&baleId=6&CategoryId=2If you try that yourself does it work?

Forget about max for this. Think about what would happen if you joined the table against itself and with the condition that the second table's rows have a higher salary than the first table's...