hackerzhou's blog Stay Hungry, Stay Foolish

在这个东东上忙了两天，基本能够处理请求了，而且效率还能接受，接下来还有很多工作来提高这个代理的throughput，减小latency，可能对现在这个模型有些改动，不过大体框架应该是这样的。对于同步编程还是有些不大顺手，有些地方需要想的比较仔细，逻辑方面不能出错，否则就死锁了，顺便向康哥请教了一些同步性方面的问题。
使用了Producer-consumer模型，处理流程如下：

1.每个request由浏览器请求了之后会被发送到Proxy，Proxy会把请求的http header以及一些其他的信息封装成一个Message对象，放到request list里面去并且wait这个Message对象。

2.ProxyTools向Conn发起GET连接，如果没有未处理的Message，返回空，即Content-Length=0。如果有，则返回这个Message里内容的BASE64编码字符串。

3.ProxyTools解码字符串，重新构造Message，然后向Web Server发起请求，得到数据。

4.ProxyTools将得到的数据和http response header等信息一起编码成 BASE64字符串，通过POST提交给Conn。

5.Conn解码字符串，取出对应的Request Message，设置response header和数据，并且把notify那个正wait在这个Message上的用户连接。

6.用户连接被唤醒后写入Message的http header和数据，关闭连接，一次请求过程结束。

接下来需要考虑的问题：
1.是否需要对html和其他text内容（比如javascript）进行链接（src，href）的改写。

2.现在ProxyTools和Conn之间使用的是无超时，即如果没有数据的话立即返回空内容，引入超时之后可能会在一定程度上提高效率，因为不需要反复建立连接了。增加超时之后由于各个链接之间的超时不一致会带来一些问题。因为服务器貌似无法知道是否客户端已经超时并断开连接了，或者是我没有找到方法，求达人指教，下午试验了一下发现居然会对客户端已经close掉的response发数据，有点诡异。

3.是否需要再建立一个队列，用于维护ProxyTools对Conn请求的response，每次有新的request message了之后从这个队列中选择一个可用的没有超时的连接发送数据。

2010年8月更新

1.在LAN端增加了负责处理Message的线程池Monitor Thread Pool，每个空闲的Monitor Thread都wait在Message Pool上。而MessageAgent只负责往Message Pool中添加获得的消息并且notify Monitor Thread，然后就返回。

2.Message Agent向HTTP Conn请求数据的时候使用有延时的HTTP链接，Message Agent端超时20秒，HTTP Conn端超时10秒，请求端一定要比响应端的超时要长。如果HTTP Conn收到Message Agent的是否有待处理消息请求后发现自己的消息池没有数据，那么就等在消息池上，超时为10秒，如果消息池在10秒只能有消息了，那么就返回给Message Agent一个OK的相应，如果10秒之后还是没消息，发送Fail相应。Message Agent在其自身超时之后默认收到了一个Fail相应。如果Message Agent收到OK，则另开一个线程去取Message，如果Fail，则继续对HTTP Conn发起询问是否有待处理消息的请求。