𝙲ℴ𝗌𝔦𝒹ₑ𝑟查看:218 回复:11 评论:218 创建时间:2022-04-02T18:40:43用户:𝙲ℴ𝗌𝔦𝒹ₑ𝑟查看:218 回复:11 评论:218 创建时间:2022-04-02T18:40:43
众所周知， 编程猫从来不会给我们充裕的云数据空间， （风纪：宁已涉嫌造谣） 面对庞大的数据储存需求， 让无数个创作者费劲了心思减少数据量储存需求。 我也是其中一员， 最近我研究zip已经。。。。。 一团糟。 ------------ 以前， 我在了解zip原理时 也了解到了喵（ptop） 原理： 其中是这样的 把一份文件拆分成若干份 让多个人下载 比一个人占领高频段宽带快得多， 然后又继续看zip了 --------------- 几天后 我突然想起喵, -如果把刷新和喵结合- -一个人有所有的云数据（相当于缓存） -然后他上传数据到云端服务器 -服务器变成了传输中枢 -服务器输出数据给其他人后，删除数据 -然后，别人再上传数据 -再传输一次。。。。 每个人都有变量，而且变量没有长度限制 我当时万分兴奋， 但是又想到是游玩者的变量作为数据库， 又正常了， 因为：必须要有一个账号在线 ---------------------------------- 以上是我设想#1的全部 如果有人真的做出来了 那么云数据的储存量将没有限制
𝙲ℴ𝗌𝔦𝒹ₑ𝑟众所周知，
云数据的容量从来不够用（）
两个列表和12个云变量的空间
不足以对抗我们庞大的数据储存需求，（）
让无数个创作者费劲了心思减少数据量储存需求。
------------
本章节和下面的有一一一一一点点关系
p_2p（ptop）
原理：
把一份文件拆分成若干份
让多个人下载
比一个人占领高频段宽带快得多，
---------------
那么我们套用一下原理
云列表是有限的
每个人进入游戏时
都会创建属于他的云变量
那么私有云变量就是无限的
一个人有所有的云数据（相当于磁盘（））
当他在线时
云端服务器传一部分数据到他的云变量里
替云列表储存
但是他不能动用那个云变量
当他更改数据时（发出请求到云列表）
传输数据到服务器（传输中枢）
服务器输出数据给其他人后，
别人的云变量就有了他的数据
云列表刚刚上传删除数据
然后别人再传输一次。。。。
但是如果代替储存的人不想玩了
就会造成数据丢失
所以要把同一个数据传输到多个人的变量里
还有，
云列表储存内容：
无法被修改的数据
和
会变动的数据
云服务器必须有自己的时钟
储存云变量也有时钟
当变量的时钟与云列表不同就要更新
以免传输到云列表的是旧数据
---------------------------------------
*本设想具有不稳定性，还没有结果实验
点赞1
评论
PAQ_Leo这样做还有一个弊端，就是现在IPV4协议已经不够用了，所以又有了NAT，当对方的WIFIIP处于不可穿透的类型就又损失了一个存储，再说，发现游戏一般是在浏览器上，别人把缓存一清。。。这不就凉了
点赞1
评论
