Meteor.onConnect: does `idString` change after a reconnect? about docs HOT 4 CLOSED

Given the user could connect to another server, I would expect it could very easily be different, yes. Have you tested it out?

from docs.

Doh. I was thinking this section of the docs was server-side. Definitely don't want to give the impression the idString is reused when connecting to different servers.

I take it an admin can use multiple Meteor servers in a load-balancing fashion, where reconnections may shift to a server with less load? I figured if a user connects to a server, loses the connection, and the client app reconnects, the client would select the same server from before.

I'm particularly interested in whether tracking connections on the server is possible in case users of publish-counts decide they want to manage the handles from Counts.publish and call handle.stop() when invoking a second subscription to avoid collisions.

I haven't tested, but will give it a go and report back.

from docs.

Finally got around to testing it out. Started out with no time, completely forgot about this, then remembered I left this lying around today.

So.

Test 1.

What if the user disconnects the app through Meteor.disconnect() and then uses Meteor.reconnect()?

I created a new Meteor 1.4.0.1 app for testing. Added two buttons to the client's page. Click one to disconnect with Meteor.disconnect(), click the other to reconnect with Meteor.reconnect(). Also display Meteor.status().status on the page to observe connection status. On the server, a Meteor.onConnection handler dumps the connection.id string to the console.

// server/main.js
import { Meteor } from 'meteor/meteor'

Meteor.startup(() => {
  Meteor.onConnection(connection => console.log(connection.id))
})

1. cd <meteor app folder>
2. run meteor to start app.
3. open http://localhost:3000 to view app.

• note the client status is connected.

4. check server console.

• note that a connection.id string is printed.

5. disconnect the client by clicking the disconnect button.

• note the client status is offline.

6. reconnect the client by (you guessed it) clicking the reconnect button.

• note the client status is connected
• note the server console shows a new-and-unique connection id string, unlike the first id string.

Conclusion:

the connection id string is always new and unique, even when the same client reconnects using Meteor.reconnect().

Test 2.

What if a network error disconnects the client and automatically restores later?

For this test, I reused the same test app from Test 1 along with some iptables-fu to simulate a network outage by dropping packets heading to the server, then later allowing packets to reach the server.

1. cd <meteor app folder>
2. run meteor to start app.
3. open http://localhost:3000 to view app.

• note the client status is connected.

4. on the server, run the command from a bash shell to simulate a network failure...

sudo iptables -I INPUT 1 -p tcp -d 127.0.0.1 --dport 3000 -j DROP

• note that the client status switches to waiting and connecting after a few (<20) seconds.
• wait for the client status to change from connected before continuing.

5. on the server, run the command from a bash shell to restore the network...

sudo iptables -R INPUT 1 -p tcp -d 127.0.0.1 --dport 3000 -j ACCEPT

• note that the client status switches to connected after a few (<20) seconds.
• note the server console shows a new-and-unique connection id string, unlike the first id string.

6. remove the iptables rule.

sudo iptables -D INPUT 1

Conclusion

the connection id string is always new and unique, even when the same client reconnects automatically after a network error.

Epilogue

I think it's safe to say that a new id (aka idString in OP) is created every time any client connects. This is consistent with the close documentation below id.

closeFunction
Close this DDP connection. The client is free to reconnect, but will receive a different connection with a new id if it does.

This answers my question. Not sure if there's any need to update the docs. Will let you have the final word @tmeasday. Close at your convenience.

Cheers.

from docs.

(Prologue: The confusing idString was a graphical error in the docs theme which was causing the field name and type to be smashed into each other and displayed confusingly. The docs now properly separate this. 😉)

I think the keyword is connection in A globally unique id for this connection.: When a connection is broken for any reason, a new connection is made and the id is regenerated.

from docs.