上周的工作，把客户端的主要的设计实现，并增添了一些新的东西，来满足一些特殊场景，主要原因是为了能够增加整个软件的可用性，不至于因为一些特殊异常就导致无法使用，同时考虑到了传输的准确性，就有增加了报文完整性验证的功能。这些工作，使得整体软件的设计，与临时增加的东西，产生了一些不协调，从目前来看，至少使得整个流程看起来有些紊乱了，因为在连接和发送报文中，增加的几种报文类型同时增加了他们对应的处理方式，这些处理方式是没有加入到整体的软件设计中的，所以存在了一定的隐患，导致这些功能软整个软件崩溃，至少是难以维护。
以上是对前面开发的思考，发现在设计阶段，如果不认证思考可能出现的情况，以及可能需要的功能的提前预设，都会是的后续开发变得紊乱，导致整个过程增加了一些可变因素，而导致不可控，虽然变化是刺激的，但有时候，太过于刺激容易导致严重的后果，并不应该在这样的事情上做过多的冒险。
这周主要是对剩下的服务端的代码进行开发。
1，为了符合时代的要求，开始研究python的非阻塞io的实现，主要是select.epoll的研究，学习了一些使用方式，并开始调试，却发现python2.7并不支持，最后只能采用bio多线程的模式来实现服务端的代码。实现的过程中，并没有考虑用线程池，而是使用的心间线程对象的方式，大概是因为觉得线程池太麻烦了（好吧，我偷懒，只是想快点看到结果）
2，原本最先想的是在prpc模组做整体流程把控的，但发现使用线程池过后，就无法在当前线程对原请求进行控制了，控制被转到了另外一个线程，这样就不得不采用链式的实现方式，在stub中导入了proxy模组，这并不规范，至少看起来并不符合两边对称的实现方式，所以思考客户端是否应该也用链路式的开发，实际上链路式的开发，会减少prpc的控制量，让他什么都不用管，直接调用proxy模组就可以了，后续的后面的模组实现他的功能即可。
3，当把请求内容的东西解析出来，并取出要请求的模组和方法名的时候，使用__import__(“prps”)动态导入模组后，并获得方法之后，才发现一个重要的问题，怎么把参数放进去，因为参数个数是可变的，总不能让远程方法都使用*args这种接受任意长度的变量吧，这样对开发者不友好，不能帮助他们理解传入参数的具体意义。所以还是要用一种人性化的方式，使得调用更友好。
4，最后查阅了python的function对象的一些属性，才发现存在_func_code_和_func_defaults_这两个属性能够帮组实现这个功能，我可以将这个函数的参数值全部设置为从客户端请求来的阐述，然后，直接不带参数的调用方法就可执行。但考虑到改变原方法的默认参数值（_func_defaults_）会给其他调用者带来影响，所以就在proxy的实现方法内部，又def了一个代理方法，该方法没有任何的代码，而是将远程方法的_func_code_赋值给这个空方法，并将他的默认参数，改为远程调用传入的参数，然后call，调用成功，返回正确的结果。
5，一切顺理成章，返回结果，封装，返回给客户端，客户端解析，并返回给方法调用者，一切结束。
6，性喜若狂，因为感觉解决了一个大问题，截了几张图，卑微的发了几张朋友圈，反复寻味这种成就感，结果是不堪不知道，一看还真的不如卸载微信，python的json包dumps和loads，默认把元组tuple转换为list，这样返回的结果跟远程方法执行的结果就不一致了，好吧，感觉有些东西要重新弄弄了，包括参数类型和结果类型都得从长计议才是，后续是不是该支持自定义类这样的结果返回还不一定。喵的，想想就不敢想。
7，好累，好累，好累，开一整天的车简直瘦不了。
网友评论