Evolution of App Communication: From JSON Text Protocol to Binary JCE Protocol in the XinYue Club App

App and backend communication typically uses text protocols such as JSON or binary protocols. This article summarizes the technical solutions adopted by the XinYue Club App’s access layer during its migration from a text‑based protocol to a binary JCE protocol, covering protocol specifications, security measures, and implementation details.

In mobile client development, data exchange with the server is essential. Initially, HTTP + JSON satisfied most needs, but as business complexity and user volume grew, performance requirements pushed the adoption of a binary protocol to reduce packet size and improve response speed.

Text protocol solution

The early version of the XinYue App used a unified PHP backend with HTTP + JSON. Requests included custom User-Agent headers (e.g., tgclub/4.1.0.63(OPPO R7;android 4.4.4;Scale/480;android;868979027609987) ) and login state stored in cookies. Request URLs followed the pattern http://xxx.xxx.com/xyapp/api/?c_ver=&mod=&act= , for example http://xxx.xx.com/xyapp/api/game/get_game_info . Responses were JSON objects containing fields such as status , errcode , and data , e.g., {"status":0,"errcode":10002,"data":"签名校验错误"} . Although concise, JSON still carries redundant field names and punctuation.

Security in the text protocol

To mitigate API leakage and request forgery, the access layer validates requests via a signature ( sn ) and a timestamp ( time_st ). The signature is generated by sorting all request parameters alphabetically, concatenating key=value pairs, appending the device‑specific secret sn_key , and applying MD5, e.g., for ?param_b=1&param_a=2&time_st=123&sn_key=aaa the signature is md5('param_a2param_b1time_st123aaa') . The server rejects requests with timestamps outside an allowed window to prevent replay attacks. Additionally, request payloads are encrypted using AES‑CBC; the encryption key pub_key is obtained together with sn_key via a registration interface.

Binary protocol solution

To further improve network efficiency, the XinYue App switched to a binary protocol based on JCE. The packet format consists of a header (containing version, length, command ID, etc.) followed by a body. Multiple command IDs can be merged into a single request, and the body may be compressed before encryption. The request header includes a sequence number, encryption method, compression method, and other metadata. The body contains a common ReqHead (device info, app version, account, network) and one or more ReqBody structures identified by cmdid . A globally unique guid is assigned to each device to avoid repeatedly sending static device information.

The response mirrors the request structure, with a RspHead providing an overall return code ( iRet ) and each RspBody containing a command‑specific return code ( ret ) and the corresponding business response data.

Security in the binary protocol

Security considerations remain similar: HTTPS is used, and the binary payload ( PkgReqBody / PkgRspBody ) is first compressed then encrypted with AES‑GCM. AES‑GCM supplies both confidentiality and integrity; the key and IV are derived from the request sequence number and a secret key. The resulting authentication tag is placed in the packet header for verification on the server side. Encryption, compression, and signature verification are encapsulated in an NDK .so library, which also checks the app signature and package name to resist reverse engineering.

Conclusion

Both text and binary protocols have advantages and drawbacks. Text protocols are human‑readable, easy to debug, and flexible for rapid changes, but they incur higher redundancy and weaker security. Binary protocols are compact, harder to sniff, and can incorporate compression and strong encryption, yet they require well‑defined specifications and more complex debugging. The choice between them should be guided by the specific scenario and performance‑security trade‑offs.