之前在做系统时有一个应用是，app、外网服务端、内网服务端、内网客户端通信互发消息，由于系统的设计，内网服务端和外网服务端被定义成为web服务器，这里的外网服务端和内网服务端没有严格的定义可以随意的替换成其他的，在我们的应用中外网服务端是一个外网的web应用的服务器，内网服务端是一个联网的内网的服务器（多个），内网客户端是一个不联网的本地程序（一个内网服务端下面有多个），app则是一个联网和外网服务端通信以及通过wifi网络和内网服务端通信的应用程序（这里略去wifi通信），消息通信的流程是，app用户根据当前的经纬度从外网服务端中获取到当前地理位置附近的内网服务端集合（每个内网服务端都在外网中能查到经纬度地址），然后app选取某一个内网服务端，并给外网服务端发一个消息，消息的内容是app用户自己的信息和内网服务端的标识符号，然后外网服务端根据app发送的消息内容中的内网服务端标识符，将app用户的信息发送到指定的内网服务端中去，内网服务端收到信息之后将app用户的信息缓存起来，以便app到达内网服务端所在地点的时候，内网的客户端通过其触发方式开始验证，在验证的时候取出缓存信息来做校验，当然其中涉及到一些其他的细节，会话缓存，心跳失效，内网服务端信息缓存，内网多客户端等等，这里就不详述了。限制条件1是外网服务端并不知道内网客户端的实际地址。在设计实现的时候想了一些思路，首先外网服务端和内网服务端通信，因为不知道内网的地址但是知道外网服务端的地址，所以采用socket的方式，套用了一个现成的框架mina，由内网服务端在启动的时候，携带一个自己的标识符（这个标识符在外网服务端的系统中是已经注册的，能找到对应的相关信息，以便和app带过来的标识符号对应），去主动的链接服务端，这里涉及到的一些链接超时失效重连等等不在详述，然后外网服务端收到内网服务端的连接之后把这个链接缓存下来，缓存的信息包括（会话本身，表示符号，连接时间戳，活跃状态，，上一次主动心跳时间戳）等等。这样一个简单的会话缓存就保存下来了。然后下一步是外网服务端等待app的访问，从访问中获取app用户自己的信息和内网服务端的标识符，然后从之前保存的socket会话缓存中找到对应的会话，如果能找到则判断活跃状态代表是否网络正常可发送，然后发送，如果没有找到对应的会话则是未注册的服务，不做处理，经过这样的逻辑之后就将消息通过流写出去，然后再返回处理结果，这样就完成了简单的一个流程。具体的部分实现程序可见之前一篇的博客（）关于其中外网服务端保存内网服务端会话的有效性以及监控所有内网服务端的网络状况，模仿心跳机制实现，参见博客（）
没有天生的信心，只有不断培养的信心。
