问题描述
各位大家好:我想做一套系统,在客户那放的是类似取票的设备,客户输入验证码后,前端设备与后台通讯,把信息提交到后台验证.后台将验证结果返回到前台设备上.前台设备再根据回传的信息做相应的控制.那么问题来了.1)我现在采用的是UDP模式,在前端设备上做了发送回应的确认处理,防止,发出的数据服务器没有收到.那我的服务器再发送回应数据的时候,还需要再等客户端再回发一次它收到我的回发数据的确认包吗?2)环境是前端设备分散在实际的商家店铺了.我的服务器准备放到IDC机房里.采用UDP通讯协议还是TCP协议呢?哪种协议更适合这样的实际环境?3)UDP我采用的是异步接收方式,然后直接send数据回去.当然这样做回应echo没什么问题.但是如果在接收到数据后,需要查询数据库做读写操作,将会花费一些时间,这样必然会拖延下次BeginReceive对上来的数据的响应.那我想在EndReceive里直接起线程处理这些业务查询并回传.然后执行后就结束了这个线程这样的处理可以吗?很多文章说起线程调度关闭线程也是非常耗时的,效果未必更好.建议用线程池来处理.我对线程池不太了解,有一个疑问,如果线程池里线程最大数是15个,那我接收到数据往线程池里加线程的时候,超过15个线程怎么办?这个过程的机制是怎么的?我认为异步同步接收和并发性没有什么关系,不知道这样的想法对与否.怎么提高并发性能呢?请各位指点迷津.
解决方案
解决方案二：
才疏学浅，只回答你第一个问题，两端用UDP通信，可以使用确认-重发机制，当一个端点发送一个新的数据包时，应当收到确认消息才能算发送成功。当然了，确认消息就不用再确认一次了，否则，这就成了一个无限的发送过程了。
解决方案三：
不知道选用UDP而非TCP是基于什么考虑，如果要求数据发送与接收高效，保证有序，有收包确认等，需要在UDP协议上构建自己的协议。这方面可以参考UDT（UDP-basedDataTransferProtocol）对于耗时操作，交互必须是异步的，否则可用性堪忧。选择单独线程还是线程池要根据业务特性，如果处理业务是长连接，那就使用单个线程。如果工作处理都是短任务，很快能结束掉，那就不要自己去起停线程，交给线程池就行。线程池出现满的情况，说明系统负载过大，超过处理能力了，这个时候如果技术上没有办法提升效率，server只能拒绝服务以保证系统的安全，否则会导致系统资源大量占用，严重的可能导致程序崩溃、系统死机
解决方案四：
to:xian_wwq我想了解一下,这样的系统结构,前端在客户店里,后端在运营商机房,哪种通讯方式比较被广泛采用.TO:johnliuyuanTHANKu