基于Java的音频转发服务器

在空余时间用Java写了一个服务器,用于转发文字、图片、音频、视频等数据,下面简要展示一下。需要源码的同学请看到文章末尾,文章末尾有资源链接。

界面模块

登陆界面

启动程序,出现登陆界面,具体界面如下图所示:
登陆界面

在端口号输入栏输入100和6000,当输入的端口号大小不在1023-65535之间或者该端口号被设备上的其他进程占用时,会弹出相应提示,如下图所示:
端口号输入错误时的提示信息端口号输入错误时的提示信息

服务器主界面

端口号测试成功后就可以点击登录按钮进入转发服务器主界面同时登录界面消失,服务器管理界面具体如下图所示:
服务器管理界面
点击在线人数监测,出现折线图动态地显示当前在线人数,时间范围(横轴数值范围)为10分钟,可以观察过去较长时间的在线人数变化;竖轴范围会根据图线的数值自动变化,以便更好的观察图表,及时发现异常情况。在线人数监测界面如下图所示:
在线人数监测界面
日志管理界面由两部分组成,第一部分是日志日期的选择,第二部分是所选日期历史日志的显示,日志管理界面具体如下图所示:
日志管理界面

消息转发功能测试

理想状态下,取CPU核心为4,CPU使用率为1,客户端只发送心跳包(5秒发一次),心跳包的平均处理时间为1.6ms(经过1000次测试得到的平均值),得到线程池大小为12500。但在实际情况下不可能达到这么大,因为数据包不止心跳包一种类型,并且数据包到来时我们需要进行日志操作和数据库操作,这很浪费时间。MySQL数据库还有最大连接数限制和最长等待时间限制,当连接过多时要么会超过数据库的最大连接数限制,要么连接需要等待很长时间才能操作数据库从而超过了MySQL数据库的最长等待时间,这两种情况都会让服务器报异常,从而使服务器无法正常工作。

系统最大连接量测试

本次测试选择的测试工具为TCP_UDP_PerformanceTest和TCPUDPDbg。用测试工具TCP_UDP_PerformanceTest向服务器定时发送心跳包(5秒一次),心跳包的十六进制形式为:fe fd 01 00 04 34 15 23 00 00 00 03 01 01 01 01 00 01 00 01 00 00 00 25 00 00 00 80 00 00 00 01 02 01 02 03 04,经过多次测试我们发现本转发服务器最多可同时支持2300个用户的连接,如果连接再多服务器就会报异常,异常原因是有些连接线程等待操作数据库的时间过长,超过了MySQL数据库的最长等待时间。具体的最大连接数测试如下图所示:
最大连接数测试

音频转发正确性测试

在上述情况下(已有2300个用户连接服务器并每隔5秒发送一个心跳包),使用测试工具TCPUDPDbg进行转发测试,用户A(ID:43415230000000301010105)和B(ID:43415230000000301010106)均连接服务器后,A向服务器发送TCP数据包,数据包中数据的十六进制形式为:fe fd 01 00 04 34 15 23 00 00 00 03 01 01 01 05 00 01 00 01 00 00 00 3f 00 0c 04 34 15 23 00 00 00 03 01 01 01 06 00 01 00 00 00 0f 05 04 00 00 00 00 0a 00 00 00 01 00 48 a0 00 01 02 03 04 ,服务器根据通信协议解析数据包后可知该数据包指令类型为“开始播发”、需要转发的数据类型是音频数据、转发对象为B以及一些其他的关键信息,具体如下图所示:
用测试工具TCPUDPDbg进行TCP消息转发测试
服务器收到该TCP数据包后会主动开启UDP转发线程,等待用户A发送到服务器的UDP数据报并转发该UDP消息给用户B。一般音频数据都较大,但UDP包的最大长度为65535字节,所以一个图片文件我们可能要分为多个UDP数据报分别发送。我们继续用测试工具TCPUDPDbg进行UDP数据转发测试,用户A用UDP向服务器发送一个音频文件,音频文件类型为mp3,用户B准备接收显示为十六进制数据并保存为音频文件,具体如下图所示:
UDP消息转发测试UDP消息转发测试
利用Beyond Compare工具比较发送与接收的音频文件,可以看到两个文件的内容是一样的,具体如下图所示:
发送(左)与接收(右)的音频文件对比
继续检测发送与接收音频文件的十六进制形式,具体如下图所示,可以看到两个文件的内容(不一样的内容会标红)是一样的,说明本转发服务器的UDP音频转发功能正常,可以准确转发音频数据。
发送(左)与接收(右)的音频文件十六进制形式对比

音频转发实时性测试

为了保证接收端能流畅地播放音频,对传输速率有一定的要求,这就对音频转发的实时性提出了要求。下面以128kbps的码率为例,因为128kpbs已经完全可以满足mp3的音质要求。
影响数据转发的实时性的因素主要有两个,一个是网络质量的好坏,一个是服务器转发过程的时延。网络质量的好坏不确定因素很大,不作为主要测试方面,这里主要测试转发服务器转发过程所需的时间,以确定在理想网络状况下本转发服务器能同时支持多少路UDP数据报的转发。测试方法为发送端循环给服务器发送1KB的UDP数据报,间隔时间为1s(选择1s发1KB数据便于计算服务器的转发性能)。服务器接收到该UDP数据报后取出数据,加上新的报头然后转发给1000个其它端口,则一次转发的数据量为1000KB,具体测试的伪代码如下:
long startTime = System.nanoTime(); // 获取开始时间
进行1000次UDP数据报的转发;
long endTime = System.nanoTime(); // 获取结束时间
System.out.println("程序运行时间: " + (endTime - startTime) + “ns”);
经长时间测试,转发过程所需时间在30ms-50ms之间波动,我们取转发所需时间为40ms。由此可以算出在不丢包的情况下,服务器转发的最大数据率为25000KB/s。前面已经提到mp3格式的音频数据率应该要不小于128kbps即16KB/s,所以可以得到在理想网络状况下本转发服务器要实现mp3音频数据的实时传输,在一路UDP数据输入的情况下,最多可支持1562路UDP数据的转发,可以满足实际应用需求。

源代码已发布在公众号“工科南”,感兴趣的同学请扫码关注公众号“工科南”并回复“01”获取源代码。
扫码关注公众号

原创文章 8 获赞 8 访问量 920

猜你喜欢

转载自blog.csdn.net/I_am_mengxinxin/article/details/102490039
今日推荐