请求代理相当于网关或者是前置机，负责接收客户端的请求报文。为了兼容原来的服务器，必须开发一个代理，负责解析报文以及做部分分发，允许将部分功能转到接新的服务模块。
单一世界本身的通讯量非常大，因此，完全依靠单一服务器来接收请求是不合理。这也是为何必须开发请求代理的原因。另外一个原因是，我认为系统的升级和变更应该是渐进式，将新系统融入并逐步替换旧系统。因为，旧系统虽然存在许多问题，但已经稳定地运行了许多时间，并受到严格地检验。一旦新系统出现缺陷，旧系统依然能够承担临时替换作用。
原来的系统中，在架构上并不是为大型系统做设计的，在容量和架构可扩展性上，受到很大的限制。请求代理的作用，是在最前端为这种可扩展性提供可能。从另一方便来说，我们对通讯协议的分析还处于起步阶段，在请求代理嵌入协议分析模块是个不错的主意。
在SPR6的认证机制中，协议报文的解析还依赖于每个帐号特有的哈希值，使得每个会话的反向解析不能有个独立的解析系统，给请求代理系统实现带来很大的难度。在代理系统中，必须取代一部分TrinitRealm的功能。
请求代理还要处理的另外一个问题是连接管理。由于所有的客户端请求都是发往代理，那么网络通道也就被建立在代理上，代理同时还必须发起另外一个请求转接到服务器中，之间的对应关系也是必须处理的。同时还是必须处理的是海量连接的问题，这个连接有可能超过了64K。我们的目标是百万连接，当然不会只在一个机器上完成。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。