For data forwarding we generally have two modes, a time-push mode, a time-pull mode. Below we briefly introduce the push mode and pull mode.
Push mode
In this mode, the message source is generally pushed directly to the target group or pushed to the broker, which is pushed by the broker to the target group.
This mode, each recipient has a copy of the data. In this case, the write pressure is very high, but the reading pressure is very small and very real-time. is a pattern of space-changing time.
Pull mode
In this mode, it is generally the message source that pushes data to the store, the target population is timed, or the pull action is taken for some reason.
In this mode, all recipients share a copy of the data. In this case, the write pressure is small, but the reading pressure is too high and the real-time is weak. is a mode of changing space in time.
The influence of two modes on system design
Push mode, the implementation looks relatively simple, but in view of the changes in the subscriber population, and so on, is not very short answer, and the consumption of storage is also very large.
Pull mode, the implementation of the trigger on the randomness is very large, and need to consider whether the number of synchronized data will bring great pressure on the network and storage.
Comet and the relationship between the two modes
Comet in essence, is an HTTP request server and the server does not currently have data, such as the server has data or more than a certain time to return to the client. At this level, comet is a mix of pull patterns and push patterns, why do you say so?
Because there are several reasons:
Comet requests the moment the server is connected, the data it concerns has changed a lot and the server can be returned to the client at once. Then this is equivalent to a pull mode where the client and the server perform checkpoint-based synchronization.
When a comet request is connected to a server, the data it is concerned about has not changed, and the data has changed during the period when the link has not timed out, and the server returns the data to the client. This is quite equal to the pull action to complete a push mode.
The application of Comet on IM
I introduced my IM group design in the previous blog. We can do it through comet. Let me briefly explain how to implement this feature.
The client uses the Post method to initiate an HTTP request in which the form {Channel1:sync_key1},{channel2:sync_key2} is requested.
When the server receives this request, it traverses all the channel as required, and if there is a change in the data, {CHANNEL1:{SYNC_KEY:SYNC_KEY1,DATA:[.....]},{CHANNEL2:{SYNC_KEY:SYNC_ key2,data:[...]}} This data form is returned.
If any channel on the server has not changed, it will be added to the subscription of all channel. When any changes are received, we traverse all channel again and return the data according to the previous data.
When the client receives the data back, it shows the data, and initiates an HTTP request with the new Sync_key, focusing on the data changes.
Application of comet technology in IM