sockets.js
8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
/**
* WebSocket Server Settings
* (sails.config.sockets)
*
* These settings provide transparent access to the options for Sails'
* encapsulated WebSocket server, as well as some additional Sails-specific
* configuration layered on top.
*
* For more information on sockets configuration, including advanced config options, see:
* http://sailsjs.org/#!/documentation/reference/sails.config/sails.config.sockets.html
*/
module.exports.sockets = {
/***************************************************************************
* *
* Node.js (and consequently Sails.js) apps scale horizontally. It's a *
* powerful, efficient approach, but it involves a tiny bit of planning. At *
* scale, you'll want to be able to copy your app onto multiple Sails.js *
* servers and throw them behind a load balancer. *
* *
* One of the big challenges of scaling an application is that these sorts *
* of clustered deployments cannot share memory, since they are on *
* physically different machines. On top of that, there is no guarantee *
* that a user will "stick" with the same server between requests (whether *
* HTTP or sockets), since the load balancer will route each request to the *
* Sails server with the most available resources. However that means that *
* all room/pubsub/socket processing and shared memory has to be offloaded *
* to a shared, remote messaging queue (usually Redis) *
* *
* Luckily, Socket.io (and consequently Sails.js) apps support Redis for *
* sockets by default. To enable a remote redis pubsub server, uncomment *
* the config below. *
* *
* Worth mentioning is that, if `adapter` config is `redis`, but host/port *
* is left unset, Sails will try to connect to redis running on localhost *
* via port 6379 *
* *
***************************************************************************/
// adapter: 'memory',
//
// -OR-
//
// adapter: 'redis',
// host: '127.0.0.1',
// port: 6379,
// db: 'sails',
// pass: '<redis auth password>',
/***************************************************************************
* *
* Whether to expose a 'get /__getcookie' route with CORS support that sets *
* a cookie (this is used by the sails.io.js socket client to get access to *
* a 3rd party cookie and to enable sessions). *
* *
* Warning: Currently in this scenario, CORS settings apply to interpreted *
* requests sent via a socket.io connection that used this cookie to *
* connect, even for non-browser clients! (e.g. iOS apps, toasters, node.js *
* unit tests) *
* *
***************************************************************************/
// grant3rdPartyCookie: true,
/***************************************************************************
* *
* `beforeConnect` *
* *
* This custom beforeConnect function will be run each time BEFORE a new *
* socket is allowed to connect, when the initial socket.io handshake is *
* performed with the server. *
* *
* By default, when a socket tries to connect, Sails allows it, every time. *
* (much in the same way any HTTP request is allowed to reach your routes. *
* If no valid cookie was sent, a temporary session will be created for the *
* connecting socket. *
* *
* If the cookie sent as part of the connection request doesn't match any *
* known user session, a new user session is created for it. *
* *
* In most cases, the user would already have a cookie since they loaded *
* the socket.io client and the initial HTML page you're building. *
* *
* However, in the case of cross-domain requests, it is possible to receive *
* a connection upgrade request WITHOUT A COOKIE (for certain transports) *
* In this case, there is no way to keep track of the requesting user *
* between requests, since there is no identifying information to link *
* him/her with a session. The sails.io.js client solves this by connecting *
* to a CORS/jsonp endpoint first to get a 3rd party cookie(fortunately this*
* works, even in Safari), then opening the connection. *
* *
* You can also pass along a ?cookie query parameter to the upgrade url, *
* which Sails will use in the absence of a proper cookie e.g. (when *
* connecting from the client): *
* io.sails.connect('http://localhost:1337?cookie=smokeybear') *
* *
* Finally note that the user's cookie is NOT (and will never be) accessible*
* from client-side javascript. Using HTTP-only cookies is crucial for your *
* app's security. *
* *
***************************************************************************/
// beforeConnect: function(handshake, cb) {
// // `true` allows the connection
// return cb(null, true);
//
// // (`false` would reject the connection)
// },
/***************************************************************************
* *
* `afterDisconnect` *
* *
* This custom afterDisconnect function will be run each time a socket *
* disconnects *
* *
***************************************************************************/
// afterDisconnect: function(session, socket, cb) {
// // By default: do nothing.
// return cb();
// },
/***************************************************************************
* *
* `transports` *
* *
* A array of allowed transport methods which the clients will try to use. *
* On server environments that don't support sticky sessions, the "polling" *
* transport should be disabled. *
* *
***************************************************************************/
// transports: ["polling", "websocket"]
};