Mina2开发网络通讯 服务器与多客户端通讯,使用Mina2开发服务器端,当接收到客户端数据时,如何做才能保证取出来的数据是完整的,而不是一部分?服务器选择性的给客户端发送数据,怎么实现?各位大侠帮帮忙,我是初学者,谢谢。 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 mina2本身服务端和客户端是以Session方式进行交流的,故,你所谓的发送数据不完整,不太明白你的意思,你可以将数据封装成对象,然后放入Session中来回传送。对于选择性发送数据,你往Session中放入客户端的特定标识就可以了。 如果是TCP的socket 没有不完整的,如果是UDP的加个分包,组包mina2服务端和客户端是以Session方式进行交流的acceptor.getManagedSessions().get(key)获得session,session.write("messoge"); 首先要了解Mina的框架结构。印象中,主要是FilterChain加Handler来完成交互过程。过滤器链,可以添加编码解码,日志输出等功能。处理器,用来完成业务逻辑部分的功能。如何做才能保证取出来的数据是完整的,而不是一部分?在过滤器链里面,都会添加ProtocolCodecFilter,根据通信协议的不同,要编写具体的ProtocolEncoder和CumulativeProtocolDecoder认真编写通信协议所对应ProtocolDecoder的代码,如果协议合理,类方法里面对象调用的方法正确的话,是不会出现数据部完整的情况的。服务器选择性的给客户端发送数据,怎么实现?这个就要看Handler类里面怎么设计了。这里实际上就是控制层的代码,这要看具体问题来做。 这需要你的报文能够标示出当前报文的结束点:1.在报文内部定义Length字段,当取出的字节数等于Length值时,即为报文结束;2.定义结束标志,例如SMTP协议已<ctrl>.<ctrl>作为结束标志,当报文读取操作读取到结束标志后,也就代表当前报文结束。显然第一种选择是更为合理的;而第二种方法存在着不确定性,除非对报文数据进行类似base64编码这样的处理,才能保证数据中不含结束标志。其实这个问题自己也一直在研究,但始终无法找到该问题的核心原因,同时对于必须使用第二种方案的协议,还是可能出现:若干报文当成一个报文的情况,希望高手解答了. 接上如果判定当前读取内容并非完整报文,需要将环境还原(即IoBuffer的各指针还原),因此如果采用Length策略,建议将Length字段放在报文头的开始字段,否则够头痛;同时doDecode方法返回false。头痛的问题留给高手了 如何做才能保证取出来的数据是完整的,而不是一部分?不知道你说的是什么?楼上已经给出答案,我就不重复了:1.在报文内部定义Length字段,当取出的字节数等于Length值时,即为报文结束; 你做通信时,肯定有一组通信协议。 你传递的可以是对象,mina里面有封装好的对象编码解码器。你也传递字节流,需要自己制定法编码解码器。然后自己组装包,包头+包体。 判断长度以及编码是否符合规则就可以判断出数据是否完整。服务器端选择性的回复就看条件了,这个没什么难度。 关于正则表达式的一个问题。 java hibernate中如何得到前十条数据 如何 一次清空 DefaultTableModel 里面的数据 求助递归方法的解决?? 怎么使用Resultset的isLast()方法? JAVA网络传输的一个问题 无法实现的同步多线程购票系统,郁闷 apache mina发送数据后session立即就关闭了 文件的读写 javamail检查邮件附件的问题 wait()和notify()简单问题 求助:贪吃蛇的两段代码问题
印象中,主要是FilterChain加Handler来完成交互过程。
过滤器链,可以添加编码解码,日志输出等功能。
处理器,用来完成业务逻辑部分的功能。如何做才能保证取出来的数据是完整的,而不是一部分?
在过滤器链里面,都会添加ProtocolCodecFilter,
根据通信协议的不同,要编写具体的ProtocolEncoder和CumulativeProtocolDecoder
认真编写通信协议所对应ProtocolDecoder的代码,
如果协议合理,类方法里面对象调用的方法正确的话,是不会出现数据部完整的情况的。服务器选择性的给客户端发送数据,怎么实现?
这个就要看Handler类里面怎么设计了。
这里实际上就是控制层的代码,这要看具体问题来做。
1.在报文内部定义Length字段,当取出的字节数等于Length值时,即为报文结束;
2.定义结束标志,例如SMTP协议已<ctrl>.<ctrl>作为结束标志,当报文读取操作读取到结束标志后,也就代表当前报文结束。
显然第一种选择是更为合理的;而第二种方法存在着不确定性,除非对报文数据进行类似base64编码这样的处理,才能保证数据中不含结束标志。
其实这个问题自己也一直在研究,但始终无法找到该问题的核心原因,同时对于必须使用第二种方案的协议,还是可能出现:若干报文当成一个报文的情况,希望高手解答了.
如果判定当前读取内容并非完整报文,需要将环境还原(即IoBuffer的各指针还原),因此如果采用Length策略,建议将Length字段放在报文头的开始字段,否则够头痛;同时doDecode方法返回false。头痛的问题留给高手了
数据是否完整。服务器端选择性的回复就看条件了,这个没什么难度。