Yesterday I added private chatting. The "whisper" option on the character context menu is now functional. There are still two problems, though:
1. Although the protocol allows it, there is no way to open a chat with someone not on the screen
2. There is no way to close chat tabs, except for reloading the website
Showing posts with label protocol. Show all posts
Showing posts with label protocol. Show all posts
Wednesday, August 7, 2013
Sunday, October 9, 2011
Another advantage of JSON: Telnet
The advantage of using a string-based protocol like JSON is that I can use a telnet client to connect to the server and to communicate with it. This allows me to examine and test the netcode directly without having to implement it in the graphical client first. I can craft short JSON messages and read the exact JSON reply.
When something doesn't work, telnetting my server helps me to troubleshoot whether it's my server which sends no or incorrect information or my client which doesn't react to it correctly.
With a binary protocol I would have to use Wireshark to sniff on the connection between client and server and then examine the hex code to get an idea of what's happening.
When something doesn't work, telnetting my server helps me to troubleshoot whether it's my server which sends no or incorrect information or my client which doesn't react to it correctly.
With a binary protocol I would have to use Wireshark to sniff on the connection between client and server and then examine the hex code to get an idea of what's happening.
Friday, October 7, 2011
JSON!
I converted the chat protocol to use JSON messages. It was much easier and straight-forward than implementing my binary protocol.
I implemented JSON parsing and encoding with JSON.simple on the Java server side. Thanks to Robert from Rojotech for his article A Review of 5 Java JSON Libraries which really helped me to choose JSON.simple over all the other JSON libraries out there.
I implemented JSON parsing and encoding with JSON.simple on the Java server side. Thanks to Robert from Rojotech for his article A Review of 5 Java JSON Libraries which really helped me to choose JSON.simple over all the other JSON libraries out there.
JSON?
I tried to implement a binary protocol the whole evening and it turned out to be a lot harder than expected. The way Java and the Metro API handle binary TCP streams is very different, resulting in very convoluted serialization and deserialization of messages.
I am currently considering to go back to string streams and use JSON to encode my network messages. This might mean some more network traffic though, especially for number-heavy messages.
When I want to tell the client that an object moved to position r:l I could do this with:
2 Bytes "this is a movement package"
4 Bytes beingID
8 Bytes position (2*float)
= 14 Byte.
In JSON this would look like this: {"type":"move", "id":1234,"r":12.000004,"l":15.9999998} which are 60 bytes in ASCII.
This might look like a large difference (1:4), but I must not forget that there is also TCP/IP overhead. When I design the protocol efficiently and send as few messages as possible, most messages will be in a single TCP/IP packet, which has an IP header of 20 bytes and a TCP header of 20 bytes. With this additional protocol overhead, the real comparison is 54 to 100 bytes - less than double.
I could reduce protocol overhead by using UDP instead of TCP which has just 8 byte of protocol overhead and has also better real-time capabilities, but with UDP I have to worry about messages disappearing without a trace or arriving in a different order than they were sent. Dealing with those situations would require additional information to be transfered which would quickly eat up the saved bandwidth.
On the other hand using JSON has a lot of advantages like making it easier to keep the protocol backward-compatible, not having to worry about different data representations and much, much easier parsing on the client side.
I am currently considering to go back to string streams and use JSON to encode my network messages. This might mean some more network traffic though, especially for number-heavy messages.
When I want to tell the client that an object moved to position r:l I could do this with:
2 Bytes "this is a movement package"
4 Bytes beingID
8 Bytes position (2*float)
= 14 Byte.
In JSON this would look like this: {"type":"move", "id":1234,"r":12.000004,"l":15.9999998} which are 60 bytes in ASCII.
This might look like a large difference (1:4), but I must not forget that there is also TCP/IP overhead. When I design the protocol efficiently and send as few messages as possible, most messages will be in a single TCP/IP packet, which has an IP header of 20 bytes and a TCP header of 20 bytes. With this additional protocol overhead, the real comparison is 54 to 100 bytes - less than double.
I could reduce protocol overhead by using UDP instead of TCP which has just 8 byte of protocol overhead and has also better real-time capabilities, but with UDP I have to worry about messages disappearing without a trace or arriving in a different order than they were sent. Dealing with those situations would require additional information to be transfered which would quickly eat up the saved bandwidth.
On the other hand using JSON has a lot of advantages like making it easier to keep the protocol backward-compatible, not having to worry about different data representations and much, much easier parsing on the client side.
Thursday, October 6, 2011
Chatting works!
The next step will be to conceptualize a proper protocol, because currently the server just forwards the text input to all clients without looking at it.
Preloading Images
Subscribe to:
Posts (Atom)