Chat Protocol

[RebelMX]

I have been reading some of the protocol documentation about the chat protocol which lists, very nicely, the packet types and their respective data.

I have a couple of questions perhaps some people could clear up:

Type      |   Sender   |   Name         |   Protocol   |   Description                                                   |   Data Format
0x00C8   |   Server   |   Normal Text   |   Both   |   For Normal text in the channel: <John> hello bob   |   [UserName:N][Text:N]{[Rank:1]}

This clearly states (as do all other sites that have a protocol listing) that this packet type is text sent FROM a chat server TO a chat client.  However it seems WinMX 3.53 and 3.54b4 as well as WPCC and Chat.Net all use this packet to send text to the server!  Is this a mistake in the documentation or is this a weird little bug?

On top of this I have noticed that many clients still send the 3.53 0x13ED packet type on joining a chat room, however they still support (and in some cases give preferential treatment to) many 3.31 protocol packet types!  Is this lazy programming or a fact that any project should support the ancient 3.31 protocol and then 3.53 as an afterthought?

This mix-and-match of a standardized protocol seems to make it difficult for any new WinMX replacement client to ever be born, and equally hard for developers to support, effectively a full protocol, as parts need to be "borrowed" from others.

Your thoughts on this would be welcome.

[Blitzen]

I would send Ghostship a PM about this, iam sure he is the person you need to speak with.

[RebelMX]

I will apologize, the information I stated about clients preferring the 3.31 protocol over 3.53 was incorrect and was actually due to text being sent prior to receiving the 3.53 server support packet (0x0068).

However I still query the fact that clients are actually supporting/using this particular packet as 3.31 protocol clients should use 0x00C9 and 3.53 should use 0x1450 for normal text?

[GhostShip]

The answer to this is one you have already hinted at RebelMX, due to the amount of older third party items out there that dont use the newer post 3.53 protocol many of the developers have ensured that both sets of protocols are supported , we are just talking chat here I hardly feel a minor issue with what chat protocol to use is even going to enter the minds of a client developer when both sets of such protocol can be supported and in fact there are many open src implementations of such support for any developer to peruse at leisure.

If any developer is reading this I would suggest they stick to supporting both types of protocol for the reason outlined above.

This chat protocol list mirrors our own here in that c8 is not even mentioned instead c9 is shown to be in use by both parties.  

http://www.hackroom.org/protocol

Looking through the src code for RoboMX (2.08, chatclient.cpp) a much featured chat client gives a coder friendly walk through this mine field of alternate packet types.

[RebelMX]

Thank you GhostShip, I do understand about supporting both protocol's and this seems the best advance.

However I am still VERY worried about this 0x00C8 packet.  As you have said, hackroom and wmw do not even have it listed, yet WinMX 3.53 and 3.54b4 as well as WPCC and Chat.Net to name a few clients, all use the 0x00C8 packet as the main 3.31 protocol send text to server.  This is in complete CONTRAVENTION with the entire protocol!  What is the point in designing a protocol when it's not even used?!?

Also I notice an error on that protocol page you listed, in that 0x00C9 is listed twice (I believe the upper one should in fact be the 0x00C8 packet) which clearly lists it as a SERVER packet not a client.  I can provide you will all the testing programs and logs if necessary to show you?

[GhostShip]

I agree the likely packet number is C8  so Ithink we should gather some data as you say and set this in stone , so perhaps a 3.31 client test to see what its used for with the Nushi sniffer (and our eyes) and then repeat the same for the 3.53 and 3.54b4 to confirm the difference and amend the documentation if required.

[RebelMX]

Here is a basic log:

15/06/2010 12:09:16 Config Loaded
15/06/2010 12:09:16 IP to Country Database Imported.
15/06/2010 12:09:16 R§WCS 1.9.5.3-TESTING ONLY!
15/06/2010 12:09:16 Server Ready
15/06/2010 12:09:16 Querying caches.winmxworld.net
15/06/2010 12:09:16 Detected IP: 78.146.203.41
15/06/2010 12:09:16 ChannelName: Test Room_29CB924E1771
-- snip --
15/06/2010 12:09:33 Type: [ 0x13ED ]  Length: [ 1 ]
15/06/2010 12:09:33 Type: [ 0x0064 ]  Length: [ 80 ]
15/06/2010 12:09:33 [C0] WinMX437_26784 Joined (127.0.0.1)
15/06/2010 12:09:36 Type: [ 0x0065 ]  Length: [ 27 ]
15/06/2010 12:09:36 [C0] Rename from WinMX437_26784 to WinMX437_25249
15/06/2010 12:10:30 Type: [ 0x00C8 ]  Length: [ 167 ]
15/06/2010 12:10:30 [C0] <WinMX437_25249> This is WinMX 3.53 in a RSWCS room.  RSWCS has been edited to not send the 3.52 compatibility packet 0x0068 on entry, so therefore clients revert to the 3.31 protocol.
15/06/2010 12:11:05 Type: [ 0x00C8 ]  Length: [ 98 ]
15/06/2010 12:11:05 [C0] <WinMX437_25249> As you will see this is sending text using the 0x00C8 packet NOT 0x00C9 as stated in the protocol!
15/06/2010 12:11:20 Type: [ 0x00C8 ]  Length: [ 66 ]
15/06/2010 12:11:20 [C0] <WinMX437_25249> Does this mean that the 2 packets are perhaps the wrong way round?
15/06/2010 12:11:28 [C0] WinMX437_25249 Disconnected (127.0.0.1)

This is a custom testing version of the server which displays the packet types and logs them as well.  I am happy to let you have a copy to use for testing yourself, otherwise please let me know which tests you would like completed.

[GhostShip]

I prefer to use WinMX for all my tests so as to retain full compatibility with the original protocol, your room log while helpful is not as definitive as a packet log such as that obtained by Nushi sniffer in a WinMX hosted chat, if you have time could you run the tests mentioned above and watch the sniffer and post the differences, this will then mean we can all agree on the exact function and amend our differing documentation to a single standard.

It's nice to see someone interested in cleaning up some of the minor points of contention in the official chat protocol, we have'nt even gotten into third party ones yet so theres still a few more items that could be cleared up for the benefit of all.

 

[Sean]

Here is a snippet from my personal chat documentation, hope the spacing is right. The yellow rows indicate WPNP 3.31 Only packets. the client ALWAYS sends text with type C8 and CA. The server can of course send types C9 and CB when clients don't support the newer protocol or in the form of "Bot Mode" as you may know. My client, Chat.Net, uses this set of packets and works great!

Type      Name            Sender     Format
200/C8   Normal Text   Client       [Text:N]
201/C9   Normal Text   Server      [UserName:N][Text:N]{[Rank:1]}
202/CA   Action Text   Client       [Text:N]
203/CB   Action Text   Server      [UserName:N][Text:N]

[RebelMX]

Thanks for this information Sean however you are wrong according to the documentation!

I point you to the following site which appears to have the most complete protocol listing:
http://web.archive.org/web/20041027202709/www.mxtools.net/?section=techie&page=cht

From this you will see
0x00C8   Server   Normal Text      Both   For Normal text in the channel: <John> hello bob   [UserName:N][Text:N]{[Rank:1]}
0x00C9   Client   Normal Text       3.31   Sends Normal Text   [Text:N]
0x00CA   Client   Action Text         3.31   Sends Action Text   [Text:N]
0x00CB   Server   Action Text        Both   For Action text in the channel: John waves to bob   [UserName:N][Text:N]
0x00D2   Server   General Text      3.53   Normally used for Server responses (eg. "Unknown Command")
0x1450   Client   Text                   3.53   Sends Text to the room (Text should be sent exactly as typed)   [Text:N]

I think we can agree that the protocol documentation on every site is wrong, and needs changing as each site has only copied the others and not checked any of the details!

On this basis:
0x00C8 should be Client 3.31 Normal Text [ Text : N ]
0x00C9 should be Server 3.31 Normal Text [ Name : N ][ Text : N ]
0x00CA should be Client 3.31 Action Text [ Text : N ]
0x00CB should be Server 3.31 Action Text [ Name : N ][ Text : N ]
0x00D2 should be Server 3.53 General Text [ Text : N ]
0x1450 should be Client 3.53 General Text [ Text : N ]

Therefore all clients should send text as:
3.53 protocol
All Text = 0x1450
3.31 protocol
Normal Text = 0x00C8
Action Text = 0x00CA

And servers should use:
3.53 protocol
All Text = 0x00D2
3.31 protocol
Normal Text = 0x00C9
Action Text = 0x00CB

Hopefully any future protocol documentation can be corrected.  I would also suggest that ALL current protocol is double checked as it appears there are at least some mistakes and it would be nice to have a definitive protocol listing so that people can look to access and utilize when they want?

[Sean]

My protocol document was based entirely off that page you posted. I updated it over time and made it prettier. I assure you that what I posted is accurate as I use it in my chat client and every other client project I ever worked on for that matter.

[GhostShip]

I dont want to appear annoying but as you say no single source of protocol is 100% in agreement on this particular chat packet and thus I would prefer we had the tests undertaken I suggested before updating anything at all.

[RebelMX]

That's fine GS, you are annoying! LOL jk

Unfortunately I am unable to perform any of these tests, i have installed fresh versions of WinMX 3.31 3.53 3.54b4 and fresh d/l's of the 2 packet sniffers, MXSniffer and MXUDP from this site and am coming up with many errors when starting WinMX with the packet sniffers included.

The exact error I encounter is:

The ordinal 9 could not be located in the dynamic link library WS2_32.dll

The number changes dependent on the WinMX version used, but the same message is displayed.  This happens on both patched and unpatched versions of WinMX.

[GhostShip]

There should be two files in the sniffer it seems as though your missing one.

[RebelMX]

Brilliant thanks, got it up and working.

As you will see from the attached screen shot (as there is no save to log file) that is the WinMX Chat Protocol page rather than the ChatRoom Chat Protocol (i.e. the send and recieve is what any chat client would do).

The text is sent as a 0x00C8 using WinMX 3.31

[GhostShip]

I think you have missed my point RebelMX but no matter I,ll do the test myself using multiple WinMX versions in both roles, the idea was that we need to test using 3 types of WinMX to fully provide the data we need to clean up the protocol documentation fully, and to ensure the data is accurate it has to be WinMX to WinMx not to a third party client or sever.