请求代理相当于网关或者是前置机，负责接收客户端的请求报文。为了兼容原来的服务器，必须开发一个代理，负责解析报文以及做部分分发，允许将部分功能转到接新的服务模块。

单一世界本身的通讯量非常大，因此，完全依靠单一服务器来接收请求是不合理。这也是为何必须开发请求代理的原因。另外一个原因是，我认为系统的升级和变更应该是渐进式，将新系统融入并逐步替换旧系统。因为，旧系统虽然存在许多问题，但已经稳定地运行了许多时间，并受到严格地检验。一旦新系统出现缺陷，旧系统依然能够承担临时替换作用。

原来的系统中，在架构上并不是为大型系统做设计的，在容量和架构可扩展性上，受到很大的限制。请求代理的作用，是在最前端为这种可扩展性提供可能。从另一方便来说，我们对通讯协议的分析还处于起步阶段，在请求代理嵌入协议分析模块是个不错的主意。

在SPR6的认证机制中，协议报文的解析还依赖于每个帐号特有的哈希值，使得每个会话的反向解析不能有个独立的解析系统，给请求代理系统实现带来很大的难度。在代理系统中，必须取代一部分TrinitRealm的功能。

请求代理还要处理的另外一个问题是连接管理。由于所有的客户端请求都是发往代理，那么网络通道也就被建立在代理上，代理同时还必须发起另外一个请求转接到服务器中，之间的对应关系也是必须处理的。同时还是必须处理的是海量连接的问题，这个连接有可能超过了64K。我们的目标是百万连接，当然不会只在一个机器上完成。