That new flag will prevent the adapter (redis) from publishing the emit to the pub/sub server.
When several instances of a server receive the same event from a third party (not from a client), each server instance broadcasts the event to all his clients. With the local flag, and the change in the redis adapter, each server instance send the event only to his client, so each client receive only one unique event.
Added a few periods and commas which were missing. Pluralised the word
'parameter' where it was incorrectly specified to singular on line 281.
Very minor edit. No source code changed.
Test 'should be able to close sio sending a port' defined a clientSocket
but didn't set 'reconnection: false'.
Now, the default behavior of a clientSocket is 'reconnection: true'.
As a result, the clientSocket was "leaked" from the test case
and seemed to intermittently connect to the servers in subsequent
test cases. This would cause other tests to timeout unexpectedly.
It's not clear to me why this would happen, since the test case
assigns a unique port number to the socket.
However, if you go into socket.io-client and assign and log
unique IDs to each socket, then you'll see that this clientSocket
shows up in other test cases if the reconnectionDelay strikes
unluckily.
Support for the serving of the client script mess with packagers like
browserify, webpack. Especcialy in projects where it is not used at all.
This patch is workaround to avoid that problem in the cases when client
script is not served.
The standard says that an ETag must be surrounded in double quotes:
https://tools.ietf.org/html/rfc7232#section-2.3
Although browsers tend to be lenient, omitting the quotes can confuse/break some kinds of proxies and other tools that demand compliant formatting. For example, Sandstorm.io enforces strict HTTP usage for security reasons and will block responses with invalid ETags.
The documentation, inadvertently, causes confusion for newer programmers, hindering their learning curve and ability to learn `socket.io` faster.
This proposed change aims at preventing this confusion to allow new programmers easier access to resources, especially when searching the web for more information.
The name `socket` in the documentation refers to the API gateway, or abstraction layer, related to the `client` and other properties. However, in the rest of the programming world, `sockets` usually refer to Berklee sockets or the lower-level communication channel that is used to implement Protocols such as the Websocket Protocol and HTTP.
New programmers often search for more informations using the `sockets` keyword when they are grappling with learning the `socket.io` API.
A good example is the stack overflow site, where newer programmers incorrectly tag their questions `sockets` and in turn don't get a fast response to their questions.
By simply changing the name of the variable used to describe socket.io's "Socket" class instances from `socket` to `client`, this mixup should be mitigated considerably.
