关于记录
记日记（笔记）能够提升一个人的自我觉察和复盘的能力。
为什么要记录？
- 最近做毕设实在有些心烦意乱，毕设这方面可参考的资料在网上确实很少，都是支离破碎没有体系的东西。所以需要做一些记录来确保每一个观点和思想的有效性和权威性。
- 除了毕设，对自己人生和生活进行一定程度的反思，从某种程度上说也是对自己生活保持一种热爱的感觉。
怎么记录？
- 可以在电脑上打字，但是有些差强人意，手还是有些累。
- 主要还是希望用手机上的讯飞输入法吧。
ps：至于记录的一些具体要点，如具体记录什么，记录流程，记录思想等以后慢慢改善吧。先是毕设要紧（太痛苦了！）。
关于毕设
这次毕设主要做的事，应该不是rpc，rpc不是重点，rpc应该只是作为一个外壳而套在里面的那个内容，它的本质还是那个sdn，还是一个网络，研究的还是网络层面的东西；但具体是你这个套的外壳怎么和这个内容的本质相连接，这才是一个问题所在，所以<u>关键问题还是把这个网络层和rpc层具体连接上来，这是主要的问题</u>。
rpc它有粘包拆包（？）的问题，这个的话还是需要具体去看一下那个理论方面的知识。
然后关于rpc时延的话，参考那个百度大佬说的话，就他除了网络时延以外，还有调度的时延，处理时延，统计调度等等（？），所以这方面就是除了网络时延这一块的其他实验都需要进行一种规定，都还需要进一步的认识，这样才能对网络时延这一块的内容呢，才能认识的更精确。
rpc和这个qos的关系是什么呢？rpc也是偏面向应用程序的，但是这qos是直接把应用层和网络层连接起来，那<u>为什么不直接用qos反倒用rpc</u>呢？这是也是一个问题。
qos的话有些应用（<u>如多媒体应用程序和交互式应用程序，VOIP</u>），比如说视频啊，语音这些等等，有些包丢掉了，语音里面有一些瑕疵，视频里面有的地方会模糊一些，但大致上他能完整地呈现给用户，所以说即使有丢包率存在，他也能一定程度上是容忍的。但是rpc不一样，rpc的话它非实时性的业务不太一样，他是零容忍的，他必须要所有的包都要全部到达，全部到达了才能合并为一个整体的rpc这个啊，这样的rpc才是被当做有效的。
一个RT-RPC，其准确性既取决于正确的执行（所以不能丢包），也取决于产生结果的时间。
总结：在规定时间内RPC拆出来的包要全部到达。
还有一个要考虑的点就是说rpc客户端这一块，除了只发一个rpc这么一种情况以外，他可能会发很多个rpc的请求，但相反这些发出去的rpc请求到达服务端之后，服务端也可以同时返回来相应的rpc响应数据，那就是客户端的网关，然后可能会同时并入并出一些rpc数据包，所以这个也是一个需要考虑的点吧，可能会导致流量拥塞等等。
现在QoS的服务，比如说区分服务和综合服务，这两个服务主要针对于目前一些特定的流，比如说数据流（？）。但是这些服务并没有太支持rpc，尤其是针对实时性的rpc（rt-rpc）。
数据流（data stream）是一组有序，有起点和终点的字节的数据序列
RPC是点对点的通讯方式，要求通讯两端必须同时运行，当其中一端挂了就会导致通常异常，并且调用者一般会阻塞住等待结果的返回，性能相对不是很高，当然也有异步RPC（？BIO和NIO等IO模型），超时重试情况下服务端提供者需要做好服务幂等性（？）处理。
