The Problem
Since Chat 2.0 has released, I've been experiencing issues with chat, like many other players I have been chatting with.
There aren't any specific errors or console logs... but instead it's the fluidity of how the chat system actually works.
The Investigation
I've noticed this problem, and, being a developer myself, am intrigued to see what's happening internally. Initially, I assumed the problem was coming from the WebSocket connection being held in one tab, and unable to be obtained in another tab because of the already open connection. Possibly, one tab has the connection and the new tab is unable to grab the connection quickly? I'm not a WebSocket expert, so I don't really know for sure. I'm just taking a wild guess. Doesn't really make since considering that Torn already uses WebSocket to achieve it's impressively quick performance.
Regardless, I know one big issue has to be local browser storage. Why doesn't Torn store previous messages into browser storage so they don't have to be fetched again for new tabs?
After investigating, I see that Torn actually uses SendBird for the chat service And, in fact, they don't use WebSocket at all. Every request for chats is made via standard HTTP/GET requests. I'm not completely sure what Torn used before Chat 2.0, but I am going to assume that Chat 2.0 was actually Torn's developer's team way of switching to a new chat provider. The chat system wasn't actually redesigned internally, but instead out-sourced to a third-party chat provider.
No problem. Hell, if you can get someone else to do it cheaper, go for it! No reason to bash on the Torn Dev team for going with a third party chat provider. For SendBird, chat is their specialty. Leave it to the pros to do the hard work. Seriously... building a chat system f**king sucks.
Unfortunately, there's a problem with SendBird. SendBird claims to be the one-stop-shop solution for chat systems. But, I don't think they're actually prepared to handle the high traffic of Torn's chat activity. At least, not in the way that Torn players are using it.
Everytime a new tab is opened, a HTTP/GET request is made to retrieve previous chat history. When opening a chat (channel), a request is made to the SendBird servers for all of this chat history. This is ridiculous for multi-tab users who are constantly switching tabs and chatting between them. The server load for SendBird must be the highest they've seen from any of their clients. The way that SendBird is delivering chats to clients is not common practice for high-load chat protocols. With 5k-10k users online at a time... SendBird is practically DDoSing themselves with all of these repetitive requests. At this rate of requests, I'm sure that SendBird probably dedicates Torn's contract to it's own servers to avoid disruption to their other customers.
The Solution
The solution here isn't pretty for Torn. I think the Torn dev team needs to develop their own chat system that is designed to work with the usage of Torn's players. This isn't an easy task... and I understand why Torn would want to outsource this responsibility to a third party. But, this is a really important aspect of playing Torn. Most players depend on communication in Torn City. Having a chat system that is designed to work flawlessly between tabs while playing Torn is essential! Local browser storage should be utilized to avoid repetitive requests. The same data shouldn't be fetched twice unless absolutely necessary. Torn is basically conducting a DDoS attack on themselves (Sendbird) by requesting the same chats, over and over, for the same user.
(edit: I do see SendBird using IndexDB, but I'm not sure if they're actually USING it. Why do they keep making GET requests for the same chat messages?)
WebSocket is already used by Torn, as obviously this is the best solution for browser-based real-time interactions. Why isn't it being used for chat?
Torn devs need to build their own chat system as a microservice. Release Torn Chat 1.0 and leave this 2.0 disaster behind.
Since Chat 2.0 has released, I've been experiencing issues with chat, like many other players I have been chatting with.
There aren't any specific errors or console logs... but instead it's the fluidity of how the chat system actually works.
- Switching between tabs can cause your previous tab's messages to not show up.
- You will see some recent messages on one tab, but on another tab, only some of those messages appear
- Chat doesn't want to connect on the current tab... let's try refreshing?? Okay, close this tab, maybe another tab will work.
- Who was I just chatting with?! Why is the chat not showing up on this new tab?
- I just sent a message, why can't I see it? Let me send it again -- Ah, theres my previous message... Oooof, sent it twice now.
The Investigation
I've noticed this problem, and, being a developer myself, am intrigued to see what's happening internally. Initially, I assumed the problem was coming from the WebSocket connection being held in one tab, and unable to be obtained in another tab because of the already open connection. Possibly, one tab has the connection and the new tab is unable to grab the connection quickly? I'm not a WebSocket expert, so I don't really know for sure. I'm just taking a wild guess. Doesn't really make since considering that Torn already uses WebSocket to achieve it's impressively quick performance.
Regardless, I know one big issue has to be local browser storage. Why doesn't Torn store previous messages into browser storage so they don't have to be fetched again for new tabs?
After investigating, I see that Torn actually uses SendBird for the chat service And, in fact, they don't use WebSocket at all. Every request for chats is made via standard HTTP/GET requests. I'm not completely sure what Torn used before Chat 2.0, but I am going to assume that Chat 2.0 was actually Torn's developer's team way of switching to a new chat provider. The chat system wasn't actually redesigned internally, but instead out-sourced to a third-party chat provider.
No problem. Hell, if you can get someone else to do it cheaper, go for it! No reason to bash on the Torn Dev team for going with a third party chat provider. For SendBird, chat is their specialty. Leave it to the pros to do the hard work. Seriously... building a chat system f**king sucks.
Unfortunately, there's a problem with SendBird. SendBird claims to be the one-stop-shop solution for chat systems. But, I don't think they're actually prepared to handle the high traffic of Torn's chat activity. At least, not in the way that Torn players are using it.
Everytime a new tab is opened, a HTTP/GET request is made to retrieve previous chat history. When opening a chat (channel), a request is made to the SendBird servers for all of this chat history. This is ridiculous for multi-tab users who are constantly switching tabs and chatting between them. The server load for SendBird must be the highest they've seen from any of their clients. The way that SendBird is delivering chats to clients is not common practice for high-load chat protocols. With 5k-10k users online at a time... SendBird is practically DDoSing themselves with all of these repetitive requests. At this rate of requests, I'm sure that SendBird probably dedicates Torn's contract to it's own servers to avoid disruption to their other customers.
The Solution
The solution here isn't pretty for Torn. I think the Torn dev team needs to develop their own chat system that is designed to work with the usage of Torn's players. This isn't an easy task... and I understand why Torn would want to outsource this responsibility to a third party. But, this is a really important aspect of playing Torn. Most players depend on communication in Torn City. Having a chat system that is designed to work flawlessly between tabs while playing Torn is essential! Local browser storage should be utilized to avoid repetitive requests. The same data shouldn't be fetched twice unless absolutely necessary. Torn is basically conducting a DDoS attack on themselves (Sendbird) by requesting the same chats, over and over, for the same user.
(edit: I do see SendBird using IndexDB, but I'm not sure if they're actually USING it. Why do they keep making GET requests for the same chat messages?)
WebSocket is already used by Torn, as obviously this is the best solution for browser-based real-time interactions. Why isn't it being used for chat?
Torn devs need to build their own chat system as a microservice. Release Torn Chat 1.0 and leave this 2.0 disaster behind.