Develop Reference

Socket.io clients seem to connect to different sockets on the same server

Hi I'm running a standard (example) socket.io chatroom, but I'm running into a problem I'm not sure how to debug.
The chatroom seems to functioning normally, clients can broadcast their messages, but occasionally on connection it is as if they are alone in the chatroom when they are not -- other clients don't see their presence or messages. It frequently happens when clients are not joining the socket around the same time.
It is as if they've connected to an entirely different socket.
I think it might be something to do with cookies and sessions. If the clients clear their sessions they are reunited in the chat.
Perhaps on (or before) connection I could clear session data? How?

There is no requirement for a chat server that clients connect on the same IP and port. Typically, there is a requirement that they connect to the same server, which must maintain a list of client connections to enable chat between them.
Chat works like this:
Server sets up a ServerSocket to accept connections. Clients connect, and these connections are stored on the Server in an array, object or some other form. When the server gets a message event from one of the clients, this message is then broadcast to all the other clients.
Thus, if you have one client who is not receiving any messages and appears to be in an empty room, the issue is likely that they are somehow not part of the same collection of connected clients, part of the same chat app, or not connected at all.

Okay I think I figured it out, I was right and wrong.
I think the clients were connecting to 'entirely different sockets' but it had nothing much to do with cookies and sessions:
I discovered (due to some other really weird bugs) by a study of running processes that somehow an old version of the socket.io server script was clinging to life in the background for some time. I expect clients were connecting to one of the two io server scripts randomly: not good. Working in a sense, but in separate worlds.
Killing those rogue processes seems to have fixed a lot of stuff.

Webrtc Getting blocked by Firewall (iceConnection:Failed)

I have simple web app,
Client1 logs in and socket connections is made to signal.php
Client2 logs in and socket connections is made to signal.php again
Client2 sends offer to client1 via signal.php
client1 sends answe to client2
ice candidiates are exchanged
So this works fine when the remote system's windows firewall is Off but when the firewall is On the ice connection fails after ice candidates are gathered.
I am using xirsys Turn/Stun servers. I have tried to find a way to find a way to make sure my app runs even if firewall is On. I have seen other webrtc example which do no get blocked by firewall. What am I missing here ?????
UPDATE
Did some more testing with following results
Does not matter if Firewall is On or Off on the client making connection. If the Firwall is On who is getting the Offer the connections fails
Example: Consider client 1 is making the offer and client 2 is receiving the offer. If client 2 has firwall On, the connection fails. If firewall is Off the connection is etablished. Does not matter if client 1 has its firewall On or Off. If client 1 and 2 or on same computer, the connections is always sucessful.

You need to compare the types of TURN servers used by your app which does not work with the ones that work. chrome://webrtc-internals shows the servers.
do you use TURN/TCP and TURN/TLS?
on which ports do the the TURN servers run?
for the working service, what kind of connection is used (see here for how to determine this)
And there are cases where the connection will fail. Your UX needs to deal with those too.

Locate server on LAN in JavaScript

TL;DR
In Javascript, how do you to find the IP of all servers running a specified program on a specified port in the LAN?
Background
I'm writing a server in node.js that is supposed to connect users browsers as controllers to a common device on which a game is running. The browsers are running a web app based on html and Javascript. The connection is based on socket.io.
I'd like for the web app to be able to find all available instances of this server in the LAN in order to create a server list for the user to choose from.
Is there a way to make the server discoverable by the web app on the local network in Javascript, and in that case: how?
Ideas
Have the server broadcast its IP to all devices on the LAN and have the web app listen for these messages (No idea how to do this without node on the client)
Connect to every IP on the network and see if the connection is successful. (Does not seem feasible)
Scan every IP on the network and connect only to those where the port is open. (Once again, no idea how to do this without node on the client and does not seeem feasible either.)
EDIT
The server is supposed to be portable and work independently, without any central system backing it up or providing matchmaking for clients. It is a LAN only server and should work even without internet access.

There is no way for you do this. Sorry. Since there is no exposure to UDP on client-side JavaScript, broadcasting is out of question. Any attempt on massive scanning will quickly raise flags on network monitoring software. You have to use a known address.

Receiving messages without port forwarding

I want a server to be able to send a client a message at any time. There may be no messages for several days, yet if one is sent, I want it to be received almost immediately (ideally within 1 second or less). How would I go about this without setting the client up as a server and using port forwarding?
An example of this would be push notifications on a mobile device. Apple can send a push notification to an iPhone almost instantly. However, the iPhone isn't acting as a server. Furthermore, the iPhone may be moving from network to network, and the networks aren't forwarding any ports to the iPhone. How does this work? Assuming there's some sort of persistent connection, how does the solution scale to hundreds of millions of devices connected at the same time?
This question doesn't depend on a particular language. I'm currently working in JS. I'm looking mostly for a conceptual answer, but feel free to answer it in the context of any language if that helps.

Remember that, once a network connection has been established, data can flow over it in either direction. There is no requirement that a peer be on the "receiving" end of a connection to receive data!
In the presence of a non-cellular network*, iPhone push notifications work by having the device connect to an Apple notification server, then wait to receive data from it. No port forwarding is necessary, as this is an outbound connection from the device. If the connection is lost, the device will reconnect to the server and "check in" to see if it missed anything.
*: If the device only has a cellular connection available, making it infeasible to keep a network connection open at all times, it may rely on notifications through the cellular network itself, kind of like SMS. But that's kind of a separate thing altogether.

For a push notification, is a websocket mandatory?

I have PHP on the server side, and HTML and javascript on the client side.
I am making an app where a stakeholder types a message that is broadcasted to multiple recievers of a group in real time.
I did some research on google and I understand I need to use WebSockets or Comet for real time push notifications. Is WebSocket or Comet mandatory for sending mass notifications to users?
Is my understanding correct? Any references to start with?

If the client is a browser, then the ONLY two ways a standard browser can connect to a server is via an Ajax (e.g. http) request or a webSocket connection. So, if you want a client to get notified of something from the outside world it has to use one of those two mechanisms.
HTTP requests are transitory. The client makes a request of a server, the server responds. HTTP requests are perfect for the client requesting information from the server. They are not very good at the server sending information to the client because normally the client is not connected. There are hacks and work-arounds where the client "polls" the server on some interval and maybe even the server uses longer running requests to try to simulate a "push" type system, but they are sub-optimal hacks at best.
webSockets are continuous connections. The client connects and the connection remains in place for as long as both sides want. This allows either side the ability to send a message to the other side whenever they want. That means the server can "push" data to the client whenever it wants. webSockets are efficient for push connections and are recommended (this is one of the main things they were designed for).
Comet is a library that was originally built for using HTTP to try to "hack" or "simulate" push before webSockets were invented and then before they were widely supported. I can think of no reason why one would want to use Comet instead of a webSocket unless you had such an old browser that webSocket was not supported.
So, if you are trying to do "realtime server push" to a browser, then you must have a continuously connected socket from the client which means webSocket (or something built on top of webSocket like socket.io).
For phone apps where you have access to the phone SDK, you can use the "push" system built into the OS to push some messages from server to client. This isn't quite the same as the two way webSocket channel, but since you asked about "push notifications", the OS push services available in both Android and IOS could also be an option for pushing notifications from server to client. Here's info on iOS notifications and Google Cloud Messaging
As of 2016, one can also use Server-sent events in all modern browsers except Microsoft browsers (not supported yet in Edge or IE) to push data from server to client. Here's a browser compatibility table. Server-sent events use a long lasting HTTP connection, a special MIME type and a supporting client in order to be able to send events from server to client at any time. Unlike webSockets, server-sent events are one way only (from server to client). A client would then use a traditional Ajax call in order to be able to send data to a server (whereas with a webSocket data can be sent either way over the same webSocket connection).
Here's a good description of how server-sent events work: How do server-sent events actually work?

Is your client application a SPA? (Single Page application)?
It's very important because if not, you have to consider that everytime a client change page, connection with websocket server will be lost.
In this case you have to manage a queue because if stakeholder send a multicast request when one client is disconnected, client won't receive nothing.
Polling won't solve this situation too and it's an orrible solution because mobile clients (for example) with typical internet plan, will consume megabytes for unuseful "ping" traffic.
A real example of polling is a child in a car asking his dad every minute if they are arrived to a destination!
So, Is there a solution without using spa?
Yes, using a "shared storage" between stakeholder and clients, and using websocket only for "wake up" online clients saying: Hey there is something new, go to check!
Everytime a client open a page it will receive from backend also not-read notifications, taken from the storage.
When a stakeholder want to notify something, it will just store the notification message in the shared storage and send a "pulse" to notification server.
Notification server will forward the "pulse" to online clients (just in case someone is stuck reading a page).
If a "pulse" is lost because a client is changing page there is no problem because the client will bring notifications from the storage.
Every page will contain this logic:
Retrive number or unread notifications (server side)
Connect to the notification server after 5 seconds (javascript side).
Hope it helps.

I would suggest that using webSockets is a more efficient way compared to other options, why is this? Well when a client receives a notification that there's a change in the server there is no need to create an AJAX call to the server to get that change, it can be sent to the client with the same webSocket connection more easily than AJAX. This means efficient code and a faster running App!