In short, I want to have an action from a client A to be viewed by client B!
I made very simple interface that changes a number and plays a sound. With help from here topic.
I thought alright simple project finished, but then realized that the computer displaying the page is not the same computer that activates the number increment.
Should I just cast the page, or is it possible to activate the sound and increment on another computer? Meaning that two clients view the same actions on the server?
Casting always look less well, because it’s a video stream. Then a crisp webpage just shown on the screen.
Server is Rpi apache.
You need a server, one computer that is the source of truth, and clients need to be connected to it. The server has the authoritative version of the count.
There are basically three realistic options for how to do this. For the examples, I’ll say there is client A, client B, and server S.
- You do what is called polling on the clients. Every n seconds, A and B poll S to check what the count is – they make a request for S to tell them. When A activates the sound, it sends a message to S, and S increments the count. The next time the clients poll, the response they get from S has the up to date count.
- You use server-sent events (SSE). For this, you use an event listener in the client code. Again, when A activates the sound, it sends a message to S. But S broadcasts the up-to-date count, sending an event. The event listener in A and B will pick this up
- You use WebSockets. A and B connect to a WebSocket channel hosted by S. Unlike 1 and 2, this does not involve a set of HTTP requests (apart from an initial request to join). A and B join a channel with S. While they are connected to that channel, messages can be freely sent and received between the connected computers. Like the SSE option, the clients can listen for messages from S, and S can listen for messages from A or B. A plays a sound, sends a message up the channel to S. S updates count, sends a message down the channel. A and B listen for that and update when the message arrives.
1: Clients send notifications to S. Clients request updates from S.
2: Clients send notifications to S. Clients listen for updates on S.
3. S listens for updates on clients. Clients listen for updates on S.
I would advise 2, it’s probably the easiest to implement for you and doesn’t have the downsides of polling (having to set up some code that runs every n seconds). 3 is the most fully featured, but that’s the downside as well – it can end up being quite complex to implement properly. 2 uses basically the same client code as WebSockets do, but overall it’s normally a lot simpler.
MDN is good on all of these things. It won’t help enormously with actually setting up the server side of things (the focus is on client-side). For server-side you’ll probably need to do a bit of reading. Note that using Node is a good choice here as you can probably get something very small together in a single file that’ll do the basics of what you want without much trouble. Anyway:
Edit: just to emphasise, just in case there’s any confusion. So what this means is that you keep all sound stuff on the client. The client’s computer runs the heavy stuff, the server is there to act as an arbiter and only deals with tiny messages.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.