You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to join an existing chatroom by name, a new chatroom is created instead of joining the existing one.
Deployment environment
version: retro_aim_server.0.4.0.linux.arm64
Install method: pre-built
Clients used: AIM 5.1.3036 on MacOS/wine
Other relevant details: Using two MacOS/wine clients, each in their own VM. VMs are NAT'd behind my laptop, so both show up as the same IP in the server logs but with separate tcp sessions.
Steps to reproduce
Trace logging enabled on retro_aim_server, running the binary directly on a rpi, with auth disabled
Login to AIM client A as Alice
Login to AIM client B as Bob
From Alice to Bob, send an instant message with a hyperlink aim:gochat?roomname=testroom&exchange=4
As Alice, click on the link
As Bob, click on the link
Observe that Alice and Bob are each in separate chatrooms but both are named testroom. Neither client show up in the 'Person Here' window for each other, and messages sent in the chat are not delivered to each other
Expected behaviour
Users joining the same chatroom with the same name and exchange should be entered into the same chatroom instance. This is how AIM behaved back in the day. The name of the chatroom was what kept a room secret or private, hence why the client generates such a long random chatroom name when creating one from the Chat button in the client.
Actual behaviour
Each user ends up in a separate chatroom.
Troubleshooting data
The client behavior is different when accepting a chatroom invite, which does work correctly, from when a new room is created or the gochat link is clicked.
In the problem case, each client clicking the gochat link ends up sending a ChatNavCreateRoom message to the server. Some speculation on my part, but it seems that the server is treating these as new separate rooms, instead of tying the rooms together by name/exchange/instance, so the list of sessions for each room remain separate.
Essentially, I think the server behavior for ChatNavCreateRoom should be looking up whether the chatroom already exists, and then treating the second client as if it has accepted an invite to the existing room.
I notice that the chatrooms work fine if Alice invites Bob to the chatroom. In this working case, Bob's client does not send a ChatNavCreateRoom message, but a series of different msgs that include OService, ChatRoomInfoUpdate, and a ChatUsersJoined for each client.
Logs, working case with invite + accept + message sent
Alice invites Bob to testroom, Bob accepts. Alice sends a message 'AAAAAAthisisatestAAAAAA'
Subject of the issue
When trying to join an existing chatroom by name, a new chatroom is created instead of joining the existing one.
Deployment environment
version: retro_aim_server.0.4.0.linux.arm64
Install method: pre-built
Clients used: AIM 5.1.3036 on MacOS/wine
Other relevant details: Using two MacOS/wine clients, each in their own VM. VMs are NAT'd behind my laptop, so both show up as the same IP in the server logs but with separate tcp sessions.
Steps to reproduce
aim:gochat?roomname=testroom&exchange=4
Expected behaviour
Users joining the same chatroom with the same name and exchange should be entered into the same chatroom instance. This is how AIM behaved back in the day. The name of the chatroom was what kept a room secret or private, hence why the client generates such a long random chatroom name when creating one from the Chat button in the client.
Actual behaviour
Each user ends up in a separate chatroom.
Troubleshooting data
The client behavior is different when accepting a chatroom invite, which does work correctly, from when a new room is created or the gochat link is clicked.
In the problem case, each client clicking the gochat link ends up sending a ChatNavCreateRoom message to the server. Some speculation on my part, but it seems that the server is treating these as new separate rooms, instead of tying the rooms together by name/exchange/instance, so the list of sessions for each room remain separate.
Essentially, I think the server behavior for ChatNavCreateRoom should be looking up whether the chatroom already exists, and then treating the second client as if it has accepted an invite to the existing room.
I notice that the chatrooms work fine if Alice invites Bob to the chatroom. In this working case, Bob's client does not send a ChatNavCreateRoom message, but a series of different msgs that include OService, ChatRoomInfoUpdate, and a ChatUsersJoined for each client.
Logs, working case with invite + accept + message sent
Alice invites Bob to testroom, Bob accepts. Alice sends a message 'AAAAAAthisisatestAAAAAA'
Logs, broken case - gochat link + sending message
Alice clicks on gochat hyperlink for testroom. Bob also clicks gochat hyperlink for testroom. Alice sends a message 'AAAAAAthisisatestAAAAAA'
The text was updated successfully, but these errors were encountered: