erlang udp即时通讯服务器开发浅谈（一）

最近在写个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 菜鸟