那山，那水，那驴

     搬到公司附近后，在回家的路上有一家超市，可以很方便的买菜。再加上回家只要10多分钟，这下可以好好的学做菜了。     其实做了几天了，都按自己小学时候的做法做(从上初中后就在学校住宿，没机会做饭了)...就是放油，盐，酱，醋...把菜炒熟就ok了。虽然谈不上好叫，但也不难吃。感觉比在外面吃好吃些，而且也实惠...    今天突然想到，可以在网上找菜谱嘛。让咱也"有据可依"的炒回菜

    累积是什么意思？累积就是我连着发送了两个1024的数据包，收到一个(只一个)ACK确认包，序号为2049，则表示我发送的两个1024的数据都已收到了。    如果收到了下一个数据包，而前一个数据包已丢失，tcp会把下一个数据包缓存在缓存区中，这时的缓存窗口变小，而且不会发送下一个数据包已到达的ACK....    有时间再画个图，就很明白了。

    写过点播后，总觉得udp的数据传输方面有很大的欠缺。。。在网速比较正常的情况下表现还可以，但如果在延迟比较大的网络中或有线通，铁通等等，表现极差...冗余比较高...    因为时间紧迫，老大建议把点播的控制机制移到直播里来。但我不同意，和老大争论了一翻后，还是决定不采纳他的意见，决定自己写一个试试    花了一天多的时间写了个比较粗糙的拥塞控制(以前花了不少时间看了这方面的资料，

    写过点播后，总觉得udp的数据传输方面有很大的欠缺。。。在网速比较正常的情况下表现还可以，但如果在延迟比较大的网络中或有线通，铁通等等，表现极差...冗余比较高...    因为时间紧迫，老大建议把点播的控制机制移到直播里来。但我同意，和老大争论了一翻后，还是决定不采纳他的意见，决定自己写一个试试    花了一天多的时间写了个比较粗糙的拥塞控制，在家里试了后，感觉还不错....(我

最近在做UGC项目，使用UDP协议上传，自己做了一层比较简单的拥塞控制，机制如下：1、每个会话都有一个发送队列，根据当前计算出的发送速率匀速发送2、服务器每秒返回一个控制消息，包含的信息有服务器接收数据包的速率和丢包率等3、客户端根据服务器返回的控制消息调整发送队列里

把一个文件拆成多个块上传机制的UDP服务器，需要注意的几点（即有文件位图，块位图的上传方式）1、被动接收端（UDP服务器）的块管理器不要限制块个数，不要有达到了几个块后删除块的想法，不然客户端和服务器的块个数不对等后，服务器端还没有上传完的数据块会被对冲掉。     服务

以前写服务器程序时，模块之间的数据传输都是通过接口来实现的，但个人认为有以下几个缺点：1、因为是同步调用，所以会阻塞消息，降低处理消息的速度，自然影响消息处理量了2、容易造成死锁如果能异步处理就很NICE了C++不知有类似成熟的模块没？