java Netty 之消息收发次数不匹配额问题

java Netty 之消息收发次数不匹配额问题

 

 

问题

 

在前面代码中,分三次发送信息:

 

 

private void sendMessageByFrame(ChannelStateEvent e) {
	String msgOne = "Hello, ";
	String msgTwo = "I'm ";
	String msgThree = "client.";
	e.getChannel().write(tranStr2Buffer(msgOne));
	e.getChannel().write(tranStr2Buffer(msgTwo));
	e.getChannel().write(tranStr2Buffer(msgThree));
}

 

 

这样的方式,连续返送三次消息。但是如果你在服务端进行接收计数的话,你会发现,大部分时候都是接收到两次的事件请求。不过消息都是完整的。

 

 

 

检查方法二

 

笔者从开始就怀疑是连续写入过快导致的问题,所以测试过每次write后停顿1秒。再write下一次。结果一切正常。

 

 

 

 

猜想原因

 

出现这样的现象,最大的原因就是缓存,连续发送太快,数据会进入到缓存,然后再定时在缓存中将数据取出来。

 

 

 

 

注意

 

   1. 有一个messageReceived事件,事件的触发,是在读取完当前缓冲池中所有的信息之后在触发的。这倒是可以解释,为什么即使我们收到事件的次数少,但是消息是完整的。

 

   2. 从目前来看,Netty通过Java 的NIO机制传递数据,数据读写跟事件没有严格的绑定机制。数据是以流的形式独立存在,读写都有一个缓冲池。

 

 

 

 

Selector模式

 

      NIO 有一个主要的类Selector,这个类似一个观察者,只要我们把需要探知的socketchannel告诉Selector,我们接着做别的事情,当有事件发生时,他会通知我们,传回一组SelectionKey,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后,我们从这个Channel中读取数据,放心,包准能够读到,接着我们可以处理这些数据。

 

Selector服务端样例代码:

 

/**
* Java NIO Select模式服务端样例代码
*
*/
public class NioSelectorServer {
 
	public static void main(String[] args) throws IOException {

		// 创建一个selector选择器
		Selector selector = Selector.open();
		// 打开一个通道
		ServerSocketChannel socketChannel = ServerSocketChannel.open();
		// 绑定到9000端口
		socketChannel.socket().bind(new InetSocketAddress(8000));
		// 使设定non-blocking的方式。
		socketChannel.configureBlocking(false);
		// 向Selector注册Channel及我们有兴趣的事件
		socketChannel.register(selector, SelectionKey.OP_ACCEPT);
		
		for (;;) {
			// 选择事件
			selector.select();
			// 当有客户端准备连接到服务端时,便会出发请求
			for (Iterator keyIter = selector.selectedKeys()
                            .iterator(); keyIter.hasNext();) {
				SelectionKey key = keyIter.next();
				keyIter.remove();
				System.out.println(key.readyOps());
				if (key.isAcceptable()) {
					System.out.println("Accept");
					// 接受连接到此Channel的连接
					socketChannel.accept();
				}
			}
		}
	}
}

 

Selector客户端样例代码:

 

/**
* Java NIO Selector模式,客户端代码
*
*/
public class NioSelectorClient {
 
	public static void main(String[] args) throws IOException {

		SocketChannel channel = SocketChannel.open();
		channel.configureBlocking(false);
		channel.connect(new InetSocketAddress("127.0.0.1", 8000));
	}
}

 

结果:

服务端接受到客户端的连接请求后,会打印出"Accept"信息。

 

 

      简单概括就是,整一个通道,通道加个选择过滤器,看来的事件是不是我想要的,不想要的干脆不管,想要的,我就存起来,留着慢慢处理。Netty的实现机制也是按照这种原理。

 

 

 

 

最后总结

 

      首先,Selector机制让我们注册一个感兴趣的事件,然后只要有该事件发生,就会传递给接收端。我们写了三次,接收端一定会出发三次的。然后,Netty实现机制里,有个Buffer缓冲池,把收到的信息都缓存在里面,通过一个线程统一处理。也就是我们看到的那个buffer的处理过程。

 

      Netty的设置中,有一个一次性最多读取字节大小的设定。并且,事件的触发是在处理过缓冲池中的消息之后。我们再来回顾一下Netty中读取信息的那段代码:

 

ByteBuffer bb = recvBufferPool.acquire(predictedRecvBufSize);

try {
	while ((ret = ch.read(bb)) > 0) {
		readBytes += ret;
		if (!bb.hasRemaining()) {
			break;
		}
	}

	failure = false;
} catch (ClosedChannelException e) {
	// Can happen, and does not need a user attention.
} catch (Throwable t) {
	fireExceptionCaught(channel, t);
}
 
if (readBytes > 0) {
	bb.flip();
 
	final ChannelBufferFactory bufferFactory =
		channel.getConfig().getBufferFactory();
	final ChannelBuffer buffer = bufferFactory.getBuffer(readBytes);
	buffer.setBytes(0, bb);
	buffer.writerIndex(readBytes);
 
	recvBufferPool.release(bb);
 
	// Update the predictor.
	predictor.previousReceiveBufferSize(readBytes);
 
	// Fire the event.
	fireMessageReceived(channel, buffer);
} else {
	recvBufferPool.release(bb);
}

 

      可以看到,如果没有读取到字节是不会触发事件的,所以我们可能会收到2次或者3次信息。(如果发的快,解析的慢,后两次信息,一次性读取了,就2次,如果发送间隔长,分次解析,就收到3次。)原因应该就是如此。跟我们开始猜的差不多。

 

 

 

 

参考:

http://www.it165.net/pro/html/201207/3219.html

你可能感兴趣的:(java Netty 之消息收发次数不匹配额问题)