Analysis and Comparison of qvod and gvod principles

Analysis on the principles of gvod and qvod online P2P On-Demand
I took the time to analyze it. The following content is my opinion. If there are any mistakes, please point out
Because I plan to develop the UT-based PNP download/on-demand software, it is necessary to first understand the two products with a large share in this field. gvod is actually developed by thunder, another one is qvod, which was developed by a company in Shenzhen. However, it is said that it has a deep relationship with the ancestor of "3721" and found the new 360, we found that qvod was used for software release.
Gvod was launched after qvod. It looks very similar, including its principles. I once asked a boss who runs their servers. One server can support so many resources, what principle does it use? The answer is broadcast. However, after half a day of consideration, I/O of tens of thousands of files cannot be imagined, and the server can be dragged to death, later, I entered several webmaster servers and used tools to analyze the CPU, Io, net process thread, and other parameters and settings of these server programs in detail. Finally, I was misled, this is neither a broadcast nor a new P2P/p2sp technology. My personal analysis suggests that it is completely old, its principle is the same as the principle of aggregate download/automatic sharing implemented in ftpanywhere, except that gvod or qvod, the behavior I call aggregation is optimized [they use the player form, but I use the download/share form]. The principle of aggregation is that if you are on a faw server, if a resource has multiple copies, you can choose to download them from multiple copies [including the master node server]. However, if qvod is used as an example, it is used differently. Dynamic judgment. If the replica resource is less than the specified number [for example, 20], it will be downloaded from the server. If it is greater than the specified number, in order to reduce the overhead of the master server, it downloads data from copies of other users and uses the most common TCP stream transmission mode. It has a very hidden behavior, that is, it will automatically share the downloaded resources, at the same time, we provide these resources to other users for download. [I didn't see whether there is such a description in its client description], and my own vlink also uses this technology, but clearly reminds users, and allows users to modify, while gvod is more concealed and cannot be deleted by general users.
Now let's take a look at their complete process. After a resource file is added, it will be released [in fact, it is a unique pattern of the computing file, that is, hash], and then the file length, file name, and other information will be extracted, combine them into a connection. When a user requests the file, first check whether the file has enough download copies. If there are enough online copies, then, the client is directly notified to download [that is, the current online client, which automatically provides bandwidth for other users to download copies while downloading], No, download from the server. If the file is downloaded from the server, check the number of connections to the file. If the number of connections exceeds the limit, the VOD may fail.
I personally think there are many problems with this technology. First, I claim to support 3-4 million servers. I personally think it is impossible because it adopts the TCP connection method, according to my personal experience and analysis, there will be a bottleneck in the connection of about 5000, And the upload speed of the user copy cannot be guaranteed, because the upload bandwidth of the user end is very limited [especially under ADSL], as a result, sometimes the server bandwidth does not have traffic, and the client will reflect the death of the card. Secondly, its P2P or p2sp technology only utilizes the simplest P2P transmission principle, there is no way to deal with a large number of concurrent users. For example, if a person's resource file is just released and 1000 people may come to VOD immediately, I am sorry, about 950 [view settings] will fail, that is, when the resources are not popular, the copy is insufficient, or the source network bandwidth of the copy is poor, a large buffer will appear [because his client is bound with the Player] Imagine that, according to my analysis, it cannot cope with the number of explosive users, and the user experience may not be good. Finally, its promotion must rely on user loyalty, that is, only the number of client installations goes up, in addition, the higher the user usage and the more fixed, then Its effect is good. On the contrary, it does not play any accelerated effect. In addition, I personally think there is no good analysis on their P2P/p2sp technology, that is, the simplest P2P transmission. I have already implemented it in the aggregate transmission protocol N years ago, but the packaging is different from the focus. I made it into a download tool, and they made it into a player.
Now, I personally think the opportunity is true. Using UT technology can completely surpass the P2P/p2sp copy mode they adopt, because the most important thing is that UT technology uses UDP for reliable transmission, the more concurrent people, the faster the speed. How many thousands of concurrent popular files are there? No problem, because ut technology uses the PNP transmission mode. While downloading, like BT, everyone exchanges downloaded blocks and broadcasts new nodes at the same time, this cannot be overcome by their technology. That is to say, they do not need any copies or loyalty. as long as a single file has enough concurrent downloads, the speed is guaranteed, whether or not to delete a file after the user downloads or watches the file has no direct impact on the server because the copy is not required. at present, the biggest problem is anti-leeching and the number of concurrent resources per server. This is a problem. According to the current technical and hardware conditions, the support for massive files has been overcome, however, the number of files that can be concurrently provided in a large number of files is about 100 in 32-Bit mode, and about 500 in 64-Bit mode, if the sub-process + multi-thread Apache method is used, the compilation is complicated.