태그 보관물: SocketChannel

넌 블럭(Non-blocking) 소켓채널(SocketChannel)에서 읽기(read) 타임아웃 처리하기..

자바의 기본 소켓채널(SocketChannel)의 read 메서드는 타임아웃(timeout)을 제공하지 않는다. 소켓채널의 socket() 메서드로 받아온 소켓객체에 타임아웃을 설정해도 타임아웃이 먹지 않는다. 기존의 스트림 기반의 네트웍 통신을 하는 애플리케이션이라면 조금 생소할 수도 있으나, read 타임아웃은 미션 크리티컬한 서버에서는 매우 중요한 이슈이다. 타임아웃이 없어서 연결이 종료가 안 되면 서버나 클라이언트가 동작을 멈추게 될 수도 있으니 말이다.

그래서, 넌 블럭(Non-blocking)의 read 메서드에 호출하기 전에 while문으로 둘러싸서 타임아웃 기능을 구현할 수 있다. 이 코드는 busy waiting하는 형태의 간단한 타임아웃 기능이 추가되었다.

// 20초                
long timeout = 20 * 1000;   
long stime = new Date().getTime();
long rtime = 0L;

int rvalue =0;
int rvalues = 0;
while (rtime < timeout ) {
	rtime = System.currentTimeMillis() - stime;
	rvalue = channel.read(rbuffer);
	if(rvalue == -1)
		throw new Exception("connection closed");

	rvalues = rvalues + rvalue;
	if(rtime > timeout)
		throw new Exception("read timeout exception");

	if(rvalues >= 4)
		break;
}

넌 블러킹(non-blocking) 소켓채널(SocketChannel)에서 끝까지 읽어오기..

넌 블러킹(non-blocking) 소켓채널(SocketChannel)에서 스트림을 끝까지 읽어오는 코드이다. 개인적으로 헤더 8byte, 헤더의 앞의 4byte를 전체 패킷을 길이로 선언했다. 그리고, 아래처럼 SocketChannel에서 packet handling variables와 같이 패킷을 끝까지 다 읽어 들인다.

아래 내용은 non-block으로 대용량의 바이너리 데이타를 읽어들이기 위해서 꼭 숙지해야 되는 내용중에 하나이다.

* read() 내용

    //// packet handling variables
    private int fullsize = 0;
    private int readedsize =0;
    private int minsize = 8;

    @Override
    public void read() {        
        try {
            // 읽기
            int rbytes = this.channel.read(rbuffer);

            // 연결종료
            if (rbytes == -1) {
                ((ChannelListener)this.listener).disconnected(this);
                this.close();
                return;
            }

            // 버퍼에 내용이 없는 경우
            if (rbytes == 0) {
                this.channel.configureBlocking(false);
                this.handle();
                return;
            } 

            // 읽은 바이트 갯수를 증감시킨다. 
            readedsize += rbytes;    
            rbufferList.add(this.copy(this.rbuffer, rbytes));

            // 최소 패킷의 길이에서 패킷을 전체 길이를 리턴한다. 
            if(readedsize >= minsize && this.fullsize == 0) {
                this.fullsize = this.createResultBuffer().getInt();
                for(int i=0; i< this.rbufferList.size(); i++) {
                    this.rbufferList.get(i).position(0);
                }
            }

            // 패킷을 다 읽어 들였다. 
            if(fullsize == readedsize) {
                ((ChannelListener)this.listener).arrived(this,this.createResultBuffer());
            }

            this.channel.configureBlocking(false);
            this.handle();
        } catch(Exception e) { // disconnected
            try {
                this.close();
            } catch(IOException ie) {
                new CallbackExceptionHandler().handle(ie);
            }

            ((ChannelListener)this.listener).disconnected(this);
        }
    }

reactor 프레임웍의 socketchannel의 read 메쏘드 호출을 어디에서??

흠…
현재 개발된 프레임웍의 구조는 master, slave reactor가 있고.. slave reactor가 네트웍 이벤트를 디스패칭을 하고있는 구조이고, 또 socketchannel의 read 메쏘드를 통해서 bytebuffer를 worker 쓰레드에 넘기는 구조인데요..

최근에 큰 사이즈의 이미지를 전송하다 보니….
worker 쓰레드에서 socketchannel의 read 메쏘드를 호출하는 것이 더 맞아보이기도 하고..

흠.. socketchannel의 read 메쏘드를 호출하는 객체가 slave reactor가 되야 될까요?? 아님 worker 쓰레드가 되야 될까요??

고민이네.. ㅜㅜ

소켓 연결 확인하기..

소켓을 기반으로 풀링을 하는 라이브러리를 개발할 시에 보통 소켓 클래스의 isconnected 라는 상태변수를 통해서 소켓의 연결상태를 확인할 수 있으나, 정확한 정보는 아니다. 그 이유가 isconnected라는 변수는, 마지막 네트웍 이벤트를 처리한 소켓의 연결 상태이기 때문이다. 그래서 확실하게 풀을 관리하기 위해서는 네트웍 이벤트를 발생시켜서 확인하는 것이 Java에서는 해결책이라고 봐야 된다. 아래의 코드로 넌 블럭(non-block) SocketChannel을 예로, read 메서드를 호출해서 결과 값으로 상태를 확인하는 코드이다.

int  readbytes = socketChannel.read(buf);
// 연결이 되어 있음..
if(readbytes == 0)
// 끊어졌네요.
if (readbytes == -1)
// 리시브된 데이타가 있네요..
if(readbytes >0)

소켓 풀링을 관리하는 매니저 클래스가 풀에 들어있는 소켓의 read 이벤트를 주기적으로 호출해보면, socket의 연결상태를 잘 유지할 수 있을 것입니다. ^^

SocketChannel에서 read()시에 계속 0을 리턴할 경우..

Selector를 통해서 클라이언트 SocketChannel을 등록하고 read 이벤트가 발생할 경우, 폴링을 하면서 read를 하지만 계속 0을 리턴하는 경우가 있습니다.. 그럴경우, read(ByteBuffer buffer)의 buffer의 position을 잘못 세팅했을 경우 발생을 합니다. 어떻게 보면 쉬운 버그이지만, 쉽게 찾아지지가 않는 다는.. ^^;;