All geek questions in one place

Designing a mobile web server and client to compress traffic

I was a little embarrassed about how best to do this.

Thing . I am creating a j2me mobile application that will send compressed data via HTTP to a web server, which then unpacks the request, extracts the data, compresses it and sends it back to the client.

One such solution: T-Booster

Problem . I was confused about how to send a compressed http request from a client application, what technology to use for the server and how best to implement it. Assuming the server is submitting thousands of requests at the same time, what will affect the entire application?

Comments are well rated. Thanks.

+4
source share
2 answers

Approach I: Best Criteria: Compression, Security, and Freedom of Architectural Design

The best way to achieve data compression is to create a custom language that is understandable only to the mobile client and its server. You can add next-level compression to it using GZIP / LZW or any other compression algorithm.

Pros:

  • Configure payload content with minimal headers and send it to the server.
  • Relatively protected from the eaves-dropper, an additional level of encryption will not harm, but will be considered based on needs.
  • Compressing towing levels reduces the overall payload.
  • It does not depend on any third-party encoder / decoder library if you do not use the GZIP / encryption libraries. Consequently, it is portable across platforms.
  • Since third-party libraries are not used, unless you use gzip and encrypt algos, there are no commercial licensing issues.

Minuses:

  • It’s hard to maintain a custom language, you need to support architecture, design and javadoc
  • The relatively high time to create a payload when using multiple compressors, namely. custom language encoding, GZIP compression and encryption library.

Example: in this link Opera Mini read the section on functionality.

.

Approach II: Upper Criteria: Strict Project Deadlines

For quick project implementation, use third-party compressors such as GZIP and industry standard web service exchange formats such as SOAP and JSON.

Pros:

  • Fast integration, following a standard approach that simplifies the development of a web server component.
  • No need to reinvent the wheel, as they say, no time is wasted on architecture and custom language development.

Minuses:

  • Level compression is managed by third-party libraries, where-in the actual content may not be compressed. The library would simply restructure an analogy with the Shannon / Speed ​​Theory.
  • Compression works the same on a low / high level device, so heap memory consumption can be blocking on low memory devices.
  • Dependence on third-party libraries, you never know when support is dropped.
  • You may fall into the vicious circle of commercial licensing when using third-party libraries if you are not using open source libraries.

Example: http://developers.sun.com/mobility/apis/articles/wsa/

.

Edit: Some very useful links

+4
source

I am not a J2ME developer, but wanted to share my view as a Java developer. If you communicate with your web server, I assume that you will call the web service (SOAP or REST). I did something similar with webservice for SOAP to compress the message a while ago. Here is what I followed. http://www.predic8.com/soap-compression-howto.htm

0
source

Source: https://habr.com/ru/post/1383754/

More articles:


All Articles