最近在写个udp 即时通讯服务器,虽然还没有写完,但是还是遇到不少的问题,需要解决。
1、通信数据格式:开始我想用自定义二进制数据进行处理,已经将握手、登陆、点对点发送消息已经写完,但此时发现这样并不合适,二进制数据读客户端来讲解析有很多困难,需要客户端开发者对二进制有比较深入的了解。经过思索后,决定还是用json来解决,虽然添加服务器的负担,但是减轻前台开发人员对协议的依赖。
2、record :随着开发的深入,发现我的考虑的通信协议、以及内部协议考虑的并不周全,途中需要经常修改,这是个很令人头疼的事情,前期会经常使用列表、或者元组封装数据结构,看似很方便,却是在后期,给我带来了很大麻烦,是我不得不去进行修改,而且修改就要修改需要很多地方,经过实践,record还是非常有用的数据结构,多层封装,且易添加新的数据结构。
3、信息接回复确认:感谢(erlang程序员群)给我很多的建议。大家也有讨论,主要集中在两点上。点对点消息发送是否需要服务器进行控制。
1)两客户端与服务器交互成功后客户端后期发送数据将不经过服务器,client-client如此发送,但是这样会出现服务器无法控制client的现象,如果出现问题(如非法问题,将无法取证),将无法采取有效的控制。
2)还有建议还是走client-server-client这样server可以进行控制,但是这样给服务器带来比较大的负载。再加上确认信息,一条信息将经过server两次(发送消息,确认消息)。
3)总结他们的讨论,我想服务器还是要进行控制的:但是控制方法我想到了两种:一种,点对点发送数据client-server-client,点对点确认信息client-client;一种,以讨论第一种方法进行处理,对聊天记录进行异步上传,这样对server的压力减轻很多,而且server也能监控到client。但是这样也会对数据进行了两次的发送,而且还带来数据的延时,可能并不是全部经由server控制。
总结上面的三点,个人觉得第二点,第三点个个有个个的优势,个人觉得第三点第二种方式还是比较好的,但我却选择的第一种,因为这跟我前期开发,已经搭起来的框架有关了,再修改就麻烦。如果今后负载过大,再换也是可以的。
以上为个人浅谈,欢迎您给出宝贵意见
erlang 菜鸟