简单的画了个草图，
白点：玩家
粉红色：设定的玩家可以交换数据的范围
蓝色：设定的玩家可以交换数据的范围，高于粉红色
绿色、紫色、红色为固定建筑。
如此一来，可以让玩家的数据在施行交换时可以采用P2P或者P2SP进行。
首先一点，这里面的固定建筑、以及周围玩家的资料服饰等，都是经过整体数据封包过的。
这样，每个玩家，每个固定建筑，甚至是很久没有改变过的土地，都可以单独成为一个封包。对应在主服务器上，其简单来说就是数据封包，和该数据封包对应的P2P、P2SP地址链接。
如此一来，数据封包完全可以当成是P2P、P2SP软件所要下载的文件。在经过主服务器验证之后，这些数据封包可以同步存放于A、B、C三个不同网络的服务器上。A：网通；B，电信；C：铁通。
以玩家为中心，最接近玩家的建筑、土地，以及其他玩家的优先级最高。如果采用P2SP的数据传输方式，则暂时不需要考虑P2P被封端口减慢网速的问问题。
玩家视野范围之内，主服务器S提供周围的玩家位置、以及对应的P2SP链接；玩家自身根据远近自动排列优先级，获取最近的建筑、人物信息，然后用P2SP的方式进行数据传输。
此方法的好处就在于，不论玩家处于什么网段，都能快速、准确的传输数据。
呵呵，有更多像豪气冲天这样的居民，就可以考虑开一个 技术开发讨论分版区了，赞！！
像sl，hipihi这样的全动态的3d虚拟世界 初衷都是瘦客户端（当然也需要客户端GPU渲染能力），
主要依仗强大的服务器端的业务逻辑运算能力。所以可能第一步还是要考虑服务器端的性能优
化方案，及服务器端的cache策略。
但和2d互联网的发展一样，在系统负载，带宽压力不断增大的趋势下，一定会考虑有效地利
用客户端被闲置的cpu，带宽，及客户端的cache策略。所以P2P正是一个可以考虑到技术方向。
但p2p技术的实际解决方案大多也需要一个中间通信服务器，所有的p2p通信请求都需要这个中间
通信服务器转发。全动态的特性必然导致p2p所带来的通信量很大。p2p建立连接也需要时间成本。
也许需要在p2p基础上做相当的改进，才能满足实时性要求比较高的全动态的3d虚拟世界的实际需
求。
Quote:豪气冲天(豪气冲天) 于2008-01-01 11:22:59 发帖:P2P的建立链接是需要时间成本，P2SP则相应的要快很多。 或许可以这样，某建筑里面的其本组件每个都是一个小的数据包，整个建筑封包之后是个大的数据包，玩家在通过P2P或者P2SP下载的时候，完成一个小数据包就显示一个。 类似现在的P2P电影，边下载边播放。
流媒体可以做到边下载边播放主要是因为流媒体协议本身的特性，视频本身也是一帧一帧为单位的。每一帧之间也相对独立。
就如同你提到的小数据包。问题是hipihi系统能否把大数据封包解耦分割成若干相对独立的小数据包（估计比较复杂）？
GPU能否独立连续地渲染这些小数据包？（看目前世界里实际渲染的过程好像能看到是一步步渲染出来的）
如果真能做到这样，带来的另一个问题就是类似“文件碎片”的问题。碎片大小的界定与业务逻辑及带宽状况都有关系。
一个目前可能就可实现的方案：服务器端可以考虑数据传输前的压缩算法，及数据分片策略（完全是数据传输层上的方案，不必考
虑业务逻辑），能实现类似断点续传的效果就很不错了：）
attachment[1]
attachment[1]