SignalR socket.connected message

A couple initial questions:

1. When is this code being executed? (i.e. after page load, inline?)
2. What is the full version of Community you're on?

1.  It's the first script tag in the widget.  It's not in any sort of document.ready structure or anything, but it's inside of a Velocity #registerEndOfPageHtml() structure.

2.  We're on Community 9.2.0.4977

Anyone?

I'm not able to recreate this yet. Would it be possible to share a Fiddler trace (or some similar HTTP trace tool) of a page load when socket.connected is not raised as expected? It may accurately indicate that the connection is not establishing. The trace would also shed some light on what transport it's using which is environment-dependent.

We do recommend initiating all widget script within a document.ready, even if it's in #registerEndOfPageHtml. That said, it shouldn't make a difference for your test case.

Also, could you expand a bit on what you're building? I'd be happy to provide tips around use of the socket framework. It may be worth noting that there have been significant updates to the socket framework in 10.x, primarily around the concept of presence. Whereas in 9.x, it was possible to send messages to individual users, in 10 it's possible to send to all users "present" to a given piece of content at a given time whether they're interacting with the content in the stream, its own page, or elsewhere. This forms the basis of 10.x's live-updating activity stream, forum threads, comments, and user presence indicators, like indicators, and more. If you are trying to send updates to all users viewing a map, for example, this could be ideal. There are also other smaller updates around socket connection durability (better reconnection, use of WebSocket protocol where available, more efficient and reliable sharing of single connections across multiple tabs, and more). Here's some more details on presence.

We've built into our community custom mapping tools.  One of those tools is to generate 'feeds' from blog, wiki, forum and media posts.  Feeds are basically an entire blog (or other application) turned into geoJson format.

Our community mapping tool ingests these feeds and displays them as map markers.  During an exercise, a giant map will be displayed for multiple users running the exercise (known as a COP map).  

The code updates I'm doing will watch for updates in applications (via create, update & delete events) and will broadcast the new geoJson feed out to those map viewers who have subscribed to the mapping socket.

The client code is all kicked off with that 'socket.connected' message, so without it, nothing updates.

This is a huge and rather complicated widget, so creating simple fiddler traces is not something I can do.

I guess at this point I'm just looking for simple best practices regarding use and placement of the subscribe code.

Sounds like an interesting project.

I'd suggest the best practice is to do all widget initiation after document.ready, including subscribing to socket.connected. All pages for authenticated users connect to the socket endpoint, whether or not the socket.connected event is subscribed to. The socket.connected event just informs other client code that the connection opened successfully. But if socket.connected isn't firing, it may be due to the connection not opening in the first place, and this is something a simple trace will show, no matter what else happens in custom widgets after the page loads. The trace will also indicate what type of transport the connection is using.

When this doesn't happen, is it for authenticated users? (sockets are disabled for non-authenticated)

When this doesn't happen, does other live functionality also not work, such as receiving notification alerts?

Also, out of curiosity, how are messages being sent from the socket plugin? If it's using ISocketController.Clients.Broadcast(), it's worth noting that this will not only send it to users who have subscribed to socket.connected. It will be received by all authenticated users in the community at the same time, no matter the page they're viewing. To be able to scope how messages are delivered, you'd need to do some level of manual mapping of users on the server side, since the only other way to direct messages is with ISocketController.Clients.Send() to a specific user. In 10.x, this works out of the box with presence services and SendToUsersPresentToContent and SendToUsersPresentToService, and it's how the other live features like forum threads and comments are updated in real-time for users on the page.

I've placed the subscription inside of a document ready.  The issue is still happening (quite frequently).

I always get "document ready" in the console, maybe 25% of the time i get "socket.connected fired..."

I'm always logged in while testing.

I do use Clients.Broadcast().  At this point I'm less concerned with how many connections get a message and more concerned with this just working.  We're doing some filtering via each map has a unique id and that's part of the message that goes out 'map.update.xxxSomeUniqueIdxxx'.  If the map id doesn't match the current map that's listening, it gets ignored.

I apologize, I've never used a trace before and am unaware of how to go about doing one.