最终,我还是认为不要用ClanLib中的socket包装类CL_Socket为好.
本来以为它还可以撑多一下,在游戏的网络功能实现才差不多再来改.
主要由3个方面考虑.
1>为每个socket加入缓冲以降底对recv函数的调用次数,另外如果使用CL_Socket中的信号通知.则有可能会漏掉一些数据包.我昨天就碰到这个
情况.当发送两次的数据包,而这边可能只会有一次信号通知,假如没有在这一次内接收完.将不会再有信号出现.因此一但对它进行等待.就会产
生超时。假如每次接收数据都使用select这类函数的话,可能会出现频繁的在用户态与内核态中来会切换,导致性能下降。
2>怎么说CL_Socket中的信号通知多了一层的调用,因为CL_Socket生成的时候都会把自已往某个线程
中添信息,以此作为信号的产生源。它中间就是用select来实现的,这样的话。通过select产生信号.
然后再在具体线程中等待这个信号,这样又多了一层关系。
3>而面对ClanLib中的网络流组件,则不知会碰到什么问题.况且以前也实现过类似的功能。因此
可以保正在短时间内完成。
因此,我今天将要实现一个类似于流这样的一个SOCKET封装.
1>假如缓冲中读取的数据包长度等于,缓冲中剩余的长度.那么就表示缓冲区可能小了。
2>SOCKET中 共享读写 缓冲区.中间以读写指针来控制其访问。
3>在Socket中的发送数据,尽量每轮在一起发送.因为以后可能会把socket中的组包算法给关闭。
4>接收Socket中的数据,应该只能从缓冲区中防问.
5>目前具体的socket还是使用阻塞模式
6>socket封装以引用对象来实现。
相应部分调整:
1>服务器中的socket监听Accept与数据处理共用一个线程。
本来以为它还可以撑多一下,在游戏的网络功能实现才差不多再来改.
主要由3个方面考虑.
1>为每个socket加入缓冲以降底对recv函数的调用次数,另外如果使用CL_Socket中的信号通知.则有可能会漏掉一些数据包.我昨天就碰到这个
情况.当发送两次的数据包,而这边可能只会有一次信号通知,假如没有在这一次内接收完.将不会再有信号出现.因此一但对它进行等待.就会产
生超时。假如每次接收数据都使用select这类函数的话,可能会出现频繁的在用户态与内核态中来会切换,导致性能下降。
2>怎么说CL_Socket中的信号通知多了一层的调用,因为CL_Socket生成的时候都会把自已往某个线程
中添信息,以此作为信号的产生源。它中间就是用select来实现的,这样的话。通过select产生信号.
然后再在具体线程中等待这个信号,这样又多了一层关系。
3>而面对ClanLib中的网络流组件,则不知会碰到什么问题.况且以前也实现过类似的功能。因此
可以保正在短时间内完成。
因此,我今天将要实现一个类似于流这样的一个SOCKET封装.
1>假如缓冲中读取的数据包长度等于,缓冲中剩余的长度.那么就表示缓冲区可能小了。
2>SOCKET中 共享读写 缓冲区.中间以读写指针来控制其访问。
3>在Socket中的发送数据,尽量每轮在一起发送.因为以后可能会把socket中的组包算法给关闭。
4>接收Socket中的数据,应该只能从缓冲区中防问.
5>目前具体的socket还是使用阻塞模式
6>socket封装以引用对象来实现。
相应部分调整:
1>服务器中的socket监听Accept与数据处理共用一个线程。