최근에 집에 있는 무선 공유기를 이용하여 다른 방에 있는 PC를 리모트에 부팅하는 방법을 알아놓은 이후로 나는 조금더 게을러 졌다. 바로 옆방에 컴퓨터가 놓여 있음에도 불구하고 말이다.

위키 디피아에서 Wake On LAN 찾아 보니, 아래와 같은 항목으로 정리 되어 있었다.

1 Technical details 1.1 System requirements - PC Compatible 1.2 How it works 1.3 Magic Packet 1.4 Security 1.5 TLS Encryption for WOL 2 See also 3 Additional resources 4 References

간략하게 요약하면,
최초에는 PC의 마더보드와 Eathernet 카드로 부터 시작이 되었는데, 이는 현재 802.11 프로토콜을 이용하는 Wake On Wireless LAN(WoLAN)으로 그 규격이 확장 되었다.

WON을 이용하기 위해서는 시스템의 Power가 최소한으로 Eathernet Card로 공급되어야 하는데, 만약 시스템의 BIOS에서 정상적으로 등록이 되지 않는다면, 이의 사용이 어려울 것이다. 그렇기 때문에 기본적인 동작을 위한 BIOS의 설정이 필요하다.

WOL이란 무엇일까?
Wake On LAN은 LAN 트래픽에 상충되지 않는다. Remote의 컴퓨터를 네트워크 상에서 동작시키는 작업을 요청할 뿐이다.
타겟 컴퓨터는 Shut down 상태에서 우리가 원하는 다른 상태로 전이 될 수 있는데 여기서 이야기하는 Shut down 상태는 "Sleeping", "Hibernateing" 또는 "Soft Off" 등이 될 수 있는데, 이 경우 역시 Power Reserved 되어 네트워크 상에서 특별한 패킷을 기다리게 된다. 이패킷을 "Magic Packet" 라고 부른다. 이 매직 패킷을 Broad casting 되어 네트워크 망을 통해서 전송된다. 그리고 이 패킷을 컴퓨터가 받았을때, Network 카드는 Packet가 정확한 정보를 포함하고 있는지 확인하게 된다. 만약 정확한 정보를 받았을 경우 Network card는 컴퓨터를 동자시키기 위해 Power을 공급하고, 시스템을 뷰팅 시키게된다.

Magic Packet에 대해서 간략하게 정리하면, 이는 Broadcate 패킷 안에 6바이트의 (FF FF FF FF FF FF)를 포함하고 있다. 그리고 타켓 컴퓨터의 MAC Address를 16회 반복하게 된다.  (아래 셈플 참조)

    FFFFFFFFFFFF010203040506010203040506010203040506010203040506
    010203040506010203040506010203040506010203040506010203040506
    010203040506010203040506010203040506010203040506010203040506
    010203040506010203040506

그리고 이 패킷을 일반적으로 UDP 프로토콜을 통해서 전송이 된다.

참고 할 수 있는 자료로는,
http://gsd.di.uminho.pt/jpo/software/wakeonlan/mini-howto/wol-mini-howto-2.html#ss2.1

를 참조하면 이해 하는데 도움이 될 것 이다.

개인적으로 구현하는 코드가 궁긍하였는데, 코드 프로젝트 사이트에 C#으로 작성된 코드가 올라와 있다.

"Wake On Lan samsple for C#"이라는 제목으로 올라와 있는데, 위에 설명한 내용을 참고하여 코드를 보면 좀더 쉽게 이해가 될 것이다.


그리고 자바 소스도 코드 프로젝트에 올라와 있다.
 - http://java.codeproject.com/KB/IP/WOL.aspx

그냥 며칠동안 테스트 코드를 작성하면서, 발견한 사실들에 대해서 겸허히 쓴다.
일민이(Toby)는 나보고 또 Spring Framework Developer Reference를 읽어보라고, 아프게 충고를 했다.

먼저, Test코드를 작성하다 보니,
BeanFactory 의 사용법과 ApplicationContext 의 사용법이 다르다는 사실을 발견했다.
사실 ApplicationContext는 BeanFactory의 인터페이스를 상속받아 만들어진 인터페이스이다. 따라서, ApplicationContext는 BeanFactory의 모든 동작을 포함하고 있고, 비슷하게 동자을 하도록 도와준다. 둘 모두 getBean() 메소드를 사용해서 Configuration을 위해 작성한 XML파일에서 정의한 Bean을 얻을 수 있다. 아까도 이야기 했지만, ApplicationContext Interface는 BeanFactory Interface의 확장이다.

ApplicationContext와 BeanFactory Interface간의 차이점은 Singleton 빈의 로딩하는 방법에 있다. BeanFatory는 getBean() 메소드가 호출될 때까지 Bean의 생성을 미룬다. 반면에 ApplicationContext는 Singleton 빈을 미리 로딩함으로 그 빈이 즉시 사용이 가능하도록 보장해 준다.

일반적인 테스트 코드를 작성할때는 두개의 차이가 거의 없을것이다. BeanFactory는 테스트 코드를 작성하기에 매우 유용하지만, 두 Interface의 차이를 알지 못하면, 이상하게 여길수도 있다. 최근에 Scheduler를 작성하게 되면서, 테스트 코드를 작성한 적이 있는데, Quertz의 Thread가 생성이 되어서 동작을 해야 하는데, 동작을 하지 않다가 getBean("scheduler")를 실행시켜줘야만 동작을 한는 것이었다. (BeanFactory 사용시)
그러나, ApplicationContext의 사용시는 ApplicatiionContext의 인스턴트가 생성되면, Quartz의 Thread가 실행되어 정해진 시간마다 Job을 실행하는 로그를 찍었다. 이유는 위에서 설명한 이유때문이다. (테스트시 ApplicationContext를 사용할 이유가 하나 늘었다.)

그리고 또하나 발견한 것은 getBean("beanId")을 통해 Bean의 reference를 얻어 올수 있다. 하지만, 가져온 Bean의 형이 내가 생각했던 것과는 다를 수도() 이는 Bean의 원 클래스에서 반환하는 오프젝트가 반환되기 때문이다.

[AbstractApplicationContext 코드 중에서]
public Object getBean(String name) throws BeansException {
  return getBeanFactory().getBean(name);

 }


만약, Factory 자체를 반환하기를 원한다면, "&"를 "beanId"앞에 붙여서 사용하면 된다.
이렇게 말이다. ==> getBean("&beanId)
이를 가르쳐 주면서 reference guide 를 잘 살 펴보라고 한다. 그래서 살펴보았더니. 딱 2줄에 걸쳐서 설명이 되어져 있다. Spring In Action에는 설명이 아예 안 되어 있다.

[BeanFactoryUtils코드 중에서]
public static boolean isFactoryDereference(String name) {
  return (name != null && name.startsWith(BeanFactory.FACTORY_BEAN_PREFIX));
 }

이 코드은 사실 AbstractBeanFactory 클래스에서 사용되는 메소드이다. 그리고
BeanFactory.FACTORY_BEAN_PREFIX 는 "&"로 정의되어 있다.