DOCX

Mobile terminal enterprise IM system optimization

By Lawrence Sullivan,2015-05-18 13:23
14 views 0
Mobile terminal enterprise IM system optimization

    Mobile terminal enterprise IM system optimization

    Imo in PC IM strong accumulation, but was in a mobile terminal has met a lot of challenges.On the mobile end relative to the particularity of bad running environment and enterprise IM (high timeliness, large amount of data), that a lot of water before effective experience, raises several issues, with some system reconfiguration and targeted positioning processing, has been resolved, this article focuses on these problems we encountered and the corresponding processing experience, hope to help everyone.

    We encountered the problem:

    1. Messaging, there will be news, news collection is not timely, message order, and so on and so

    forth.

    2. Giant structure update slow, high failure rate

    3. Voice message to upload, download high failure rate, poor experience

    4. Embedded web applications at a slower speed, less experience

    For more than we were analyzed by orientation, to comb structure, process, all problems solved, the reliability of the mobile terminal IM experience achieves the WeChat level.

    A. Mobile message mechanism optimization - > mobile environment messaging mechanism (messaging reliability, timing guarantee)

    1. The traditional PC solutions

2. Mobile environment optimization framework

    Refer to the above two pictures, the traditional PC IM architecture, from the Server (from the sender ClientA after receiving the message, the initiative will be pushed to the receiver ClientB, effective this way in the PC environment, push the success rate can reach 90%, push failure records offline message, the client will be in the login to get offline messages.Here the entire process, the server end has been in active role, the client is in a passive role, business logic server end to identify according to the situation and deal with.

    But when we switch to the mobile terminal when the scene, everything changed, we found that the server actively push the success rate is extremely low, because the server push, rarely in a TCP connection state stable mobile client, may be in the network is not stable, the app in the background, make a phone call to wait for all sorts of scenarios.Aimed at this situation, we think, how to solve to solve so many things, don't want to do for each case judgment?Do so, the basic is a bottomless pit.After thorough analysis, we found that the crux of the problem is that we should try to avoid these scenarios from the architecture of the particularity of processing, how to do?We use the relevant document, refer to Microsoft's ActiveSync mechanism, change the message mechanism from the server push pull to client, in this mode, the server only need the message is effective, the client can choose at any point in time, pull any number of message, so, we from the fundamental doubts logic in addition to the possibility of lost messages.At the same time, we combine the heartbeat and notify, inform the client on the server to see if there is new news, also solves the problem of timeliness of information.

    On the basis of the above optimization, we to the global number of news, news and orderly global id as the synchronization mechanism of Sync above the benchmark, and at the same time as a message to heavy, and the message ordering basis, rule out the possibility of duplication and out-of-order.

    At this point, with the support of the new message mechanism, we did 100% of the mobile terminal of the IM message reliability, to improve the robustness and usability of nature.

    2. Mass organization structure synchronization (more than 1 w) - through the UC version control thin enough, dispersion of data to send, to cumulatively, granular ants moving way gradually to the data you need

    This link is unique to the enterprise IM special scenario.According to statistics, 99% of people contact number in my address book in 500, under the orders of magnitude, common personal end products in this does not need to spend too much energy.IM and enterprise environment, 1000 is just a starting point, large enterprises need to be able to support more than 10000 people, even in the organizational structure of more than 100000 people, under the orders of magnitude, the traditional solution of the basic solution.In addition, we have no similar products of the basic solution to this problem can be reference, only yourself.

    We face the main problem is that the giant structure update slow, high failure rate.Through the concrete analysis, we found that the core of the problem is a small amount of information in the organization structure change, will cause changes in the global, leading to massive amounts of updating data checking, and in the mobile environment, basic won't have enough bandwidth and running time, to complete the process, so that make it difficult to succeed in the update.

    Ideas:

    Aimed at this situation, we found that a similar scenario is in SVN managing large code base will also meet, but the SVN is very good to solve the problem.So, we analyzed the SVN solution, refer to the thinking of it, keep all Server version (3 months), granular version of the diff.Client only pull specific granularity of diff data, and data merging.

    Specific process is as follows:

    Server for each node in the background (Dept) department to maintain the whole version list, each branch node changes (add or delete a department and the department members) after data submission, can lead to the department of the original data is stored as a version of the history and the uc version corresponds to modify before;

    When the client use the local store the uc to the server for a department of synchronous data, the department pass server is the client to the uc and the department is currently the latest uc, if uc is different, the calculation amount of the difference between the two versions of the data, and the dispersion of data back to the client;After the client receives, the dispersion of data and save the original data is calculated with the department, it is concluded that the department of the latest data, update the data in the local database and interface;

    The client can selectively update specific dept, there is no strong dependence between different dept.

    Through the above method, no matter how large is the organizational structure, no matter what kind of update, we almost all the mobile client can smoothly complete the update, basically solved the mass organization architecture enterprise IM environment problems.

    3. The voice optimization

    Classic IM solution, the voice as 2 hexadecimal file processing, recording first and save as a file, and upload via HTTP.

    According to this scheme, the first edition voice upload failure rate is high, especially in the continuous speech to send, after analysis we locate here are some points:

    1. Voice using the built-in amr coding, the voice message, the rate is too high, our voice of big

    amount of data in a minute.

    2. Send the continuous speech, there are multiple uplink channel, preemption is too large for

    bandwidth

    3. HTTP upload, in the mobile terminal, ios, android provides HTTP library cannot be reliable for

    long HTTP connection to keep, in most cases, the HTTP request to create a TCP connection.

    4. A single TCP connection setup cost is high

    5. Users will soon after send the voice to exit the dialog interface or will cut into the background, the

    app can perform time too short

    Voice task flow chart

    In view of the above points, we respectively from the decoding process, optimized transmission channel of three aspects:

    A. codec: after testing, comparison, comprehensive quality and the amount of data, chose iLBC as cross-platform speech coding, iLBC made specifically for voice call optimization, very suitable for narrow-band environment (mobile) voice communications, qq super voice codec is based on this, Google in webrtc face iLBC made open source code.ILBC can make our voice in relative to ensure quality under the condition of small data quantity.

    B. process: the original process will appear multi-channel preempt the bandwidth, the similar highway, together with the running result is all not.Move the bandwidth in GPRS only a few K, so that the bandwidth of the upload can barely hold up all the way.Aiming at this situation, we have designed a priority task queue, at the same time ensure that only a task in the upload, into in accordance with the principle of FIFO queue, the ability to provide the priority queue.As flow chart, such basic solved the channel congestion, as long as there is network, upload task can be completed sooner or later.

    C. channel: in GPRS environment next time a TCP connection to establish 5 s is the average time, this price we can't afford, but we also found that we IM signaling communication TCP connection channel is very stable.In view of this, we will try to upload the task through IM TCP, long connection to perform, at the same time to record while the way.Through the AB Test, we found that the optimization is very effective, single completion of speech task have made a lot of ascension.The relative amount at the same time, the voice of the data is not large, so, no big influence on our signaling channel.In addition, considering the special situation, we still retain the HTTP channel, by the TaskHandler to choose according to actual business scenarios.

Report this document

For any questions or suggestions please email
cust-service@docsford.com