Microsoft MVP성태의 닷넷 이야기
.NET Framework: 96. WCF - PerSession에서의 클라이언트 연결 관리 [링크 복사], [링크+제목 복사],
조회: 29814
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

WCF - PerSession에서의 클라이언트 연결 관리


일단, 오늘의 주제는 아마도 많은 분들이 관심있으신 사항이었을 거라 봅니다. PerCall 모드에서야 별로 관심 없을 사항이겠지만, PerSession에서는 클라이언트 연결 관리가 꽤나 중요한 요구 사항으로 대두됩니다. 일례로, PerSession에서 "Callback"을 쓰려고 해도 현재 제대로 연결된 클라이언트를 알아야만 효율적인 콜백 호출을 할 수가 있기 때문입니다.

어디... 코드와 함께 조금씩 문제를 파헤쳐 볼까요? ^^

대개의 경우, WCF (세션 가능한) 서비스 코드는 다음과 같은 구조를 이룹니다.


///// 서버 측 코드 //////

[ServiceContract(SessionMode = SessionMode.Required)]
public interface IService1
{
  [OperationContract]
  void StarDust();
}

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
public class Service1 : IService1
{
  public void StarDust()
  {
  }
}

클라이언트는, 다음과 같이 인스턴스 변수로 관리를 할 테지요!

Service1Client svc;

private void Form1_Load(object sender, EventArgs e)
{
  svc = new Service1Client("NetTcpBinding_IService1");
}

private void Form1_Close(object sender, EventArgs e)
{
  svc.Close();
}

뭐... 대충, 위와 같은 선에서 서비스가 제작될 것입니다. 여기까지는 별다른 이상이 없어 보입니다. 하지만, 여기서 콜백이 들어가면 상황이 달라집니다.

우선, 서버 측 코드는 다음과 같이 바뀔 테고.

// 콜백 인터페이스
public interface IMyServiceCallback
{
  [OperationContract(IsOneWay = true)]
  void FallingStar();
}

// 콜백 인터페이스를 지정
[ServiceContract( SessionMode = SessionMode.Required, CallbackContract=typeof(IMyServiceCallback))]
public interface IService1
{
  [OperationContract]
  void StarDust();
}

// 콜백을 추가
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
public class Service1 : IService1, IDisposable
{
  static Dictionary<string, IMyServiceCallback> callbacks 
  = new Dictionary<string, IMyServiceCallback>();
  public void StarDust()
  {
    string id = OperationContext.Current.SessionId;
    IMyServiceCallback callback = OperationContext.Current.GetCallbackChannel<IMyServiceCallback>();

    if (Service1.callbacks.ContainsKey(id) == false)
    {
      // 새로 연결된 세션의 콜백을 추가
      Service1.callbacks.Add(id, callback);
    }
  }
}

클라이언트 측에서는 콜백 인터페이스 구현 및 관련 메서드를 호출하도록 구성합니다.

public partial class Form1 : Form
     , IService1Callback 
     // 프록시 코드 생성 시, 서버 측의 IMyServiceCallback 이름이 
     // [서비스 이름] + "Callback" 형태로 바뀝니다.
{
  Service1Client svc;

  private void Form1_Load(object sender, EventArgs e)
  {
    InstanceContext instance = new InstanceContext(this);
    svc = new Service1Client(instance, "NetTcpBinding_IService1");
    try
    {
      svc.Open();
      svc.StarDust();
    }
    catch (Exception ex)
    {
      Console.WriteLine(ex.Message);
    }
  }
}

public void FallingStar()
{
  Debug.WriteLine("To Become an woman.");
}

서비스 측 코드를 보시면, ... 뭔가 이상한 것을 발견할 수 있습니다. 서버 측의 콜백 관리가 Add만 있을 뿐, Remove가 없습니다. ^^;

그렇습니다. 문제는, 해당 콜백의 remove를 언제 하느냐는 것입니다.

개인적으로, 이 부분에 고민을 하면서 ... 예상했던 것과는 달리 그와 관련된 자료가 거의 없다는 것을 알았습니다. 어떤 토픽을 읽어보니, 콜백 함수 호출 시에 명시적으로 오류가 발생하면, 그것을 연결이 끊겼다고 판단하고 콜백에서 지우는 것을 보았습니다.... 음... ^^; 언뜻 봐도 그것은 비이성적인 방법이라고 밖에는 볼 수 없습니다.

그러다가, 아래의 토픽에서 좀 더 나은 방법을 발견했습니다.

2006년 12월호 닷넷 칼럼 ::  WCF Instance Management 
; http://www.simpleisbest.net/articles/1731.aspx

위의 토픽에는, 아래와 같이 아주 "기본"적인 내용의 해결책이 담겨져 있었습니다. (역시, 기본에 충실해야 합니다. ^^)

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class PerSessionService : IEchoService, IDisposable
{
  private int _CallCount = 0;

  public PerSessionService()
  {
    Console.WriteLine("PerSessionService Created...");
  }

  public void Dispose()
  {
    Console.WriteLine("PerSessionService Disposing...");
  }
}

처음엔, 위의 코드를 발견하고 굉장히 ^^ 좋아했습니다. 하지만, 조금 있다가 이것도 뭔가 부족하다는 것을 알게 되었습니다. 예를 들어, 현재의 연결이 "비정상 종료"인지, Close를 통한 정상적인 종료인지를 알 방법이 없다는 것입니다. 또는 현재 Dispose가 실행되는 연결 상태의 정보를 알 수가 없다는 것입니다. (물론, 적절한 인스턴스 변수를 보관해 두면 가능하지만.)

그래도 왠지... ^^ 이거 말고 다른 방법이 없을까... 하는 의문이 들었습니다.

검색을 제법 하다가,,, 드디어 그럴싸한 방법을 하나 발견했습니다.

Recover from Abort on ServiceChannel 
; http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1667130&SiteID=1

와... ^^ 꼭꼭 숨겨져 있는 기능을 찾은 기분입니다.

방법은, 간단합니다. OperationContext.Current.Channel.Faulted 이벤트와 OperationContext.Current.Channel.Closed 이벤트를 이용하는 것입니다. 이를 이용해서 서비스 측 코드를 다음과 같이 개선할 수 있습니다. (가만히 생각해 보면, 이것 역시 기본에 충실했으면 자연스럽게 알 수 있었을 내용이죠!)

public void StarDust()
{
  IMyServiceCallback callback = OperationContext.Current.GetCallbackChannel<IMyServiceCallback>();
  string id = OperationContext.Current.SessionId;

  OperationContext.Current.Channel.Faulted += new EventHandler(Channel_Faulted);
  OperationContext.Current.Channel.Closed += new EventHandler(Channel_Closed);

  lock (Service1.callbacks)
  {
    if (Service1.callbacks.ContainsKey(id) == false)
    {
      Service1.callbacks.Add(id, callback);
    }
  }
}

void Channel_Closed(object sender, EventArgs e)
{
  UnregistCallback(sender as IClientChannel, true);
}

void Channel_Faulted(object sender, EventArgs e)
{
  UnregistCallback(sender as IClientChannel, false);
}

void UnregistCallback(IClientChannel channel, bool closedGracefully)
{
  string txt = channel.SessionId;

  lock (Service1.callbacks)
  {
    if (Service1.callbacks.ContainsKey(txt) == true)
    {
      Service1.callbacks.Remove(txt);
      Console.WriteLine(txt + " : removed");
    }
  }
}

아쉽게도, Faulted/Closed 이벤트 핸들러에서의 OperationContext.Current는 null 값이지만, sender 값을 형변환해서 channel 정보를 받을 수 있기 때문에 해당 세션에 대한 다양한 정보를 구할 수가 있습니다. 또한, 비정상 종료를 하는 클라이언트 연결 개체까지도 모니터링 할 수 있기 때문에 경우에 따라서 클라이언트 측의 연결 중에 정상적으로 Close로 닫히지 않는 경우도 알아낼 수 있습니다.

참고로, 순서상으로 보면, Dispose 메서드가 먼저 실행되고 Closed/Faulted 이벤트 핸들러가 실행이 됩니다.

뭐... 이 정도면 되겠지요! ^^



[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2009-01-03 03시32분
[초보^^] 감사합니다!! 많은 도움이 되었습니다^^
[guest]
2009-01-03 07시59분
^^
kevin25
2009-11-05 12시48분
[초보] 안녕하세요 ^^

이글에 대한 질문이 있는데요..

클라이언트의 프로세스가 비정상적으로(예를 들면 프로세스가 죽어 버리는) 종료 되면

Closed, Faulted 이벤트 핸들러에도 안들어 오더라구요..

혹시 이런 상황에서 callback channl를 관리 하는 방법은 없나요 ???
[guest]
2009-11-05 01시15분
말씀하신 그런 부분은 모든 소켓 관련 로직에서 고민되는 부분입니다.
물론, WCF에서는 이에 대한 고려가 되어 있고 관련해서는 다음의 글을 참고하십시오.

netTcpBinding에서의 각종 Timeout 값 설명
; http://www.sysnet.pe.kr/2/0/536

위의 설명에서 receiveTimeout, inactivityTimeout 등의 설정이 "초보" 님이 원하시는 답입니다.
kevin25
2009-11-05 04시57분
[방금그초보] 답변 감사 합니다..

열심히 공부 해야 겠네요 ^^;;
[guest]

... 181  [182]  183  184  185  186  187  188  189  190  191  192  193  194  195  ...
NoWriterDateCnt.TitleFile(s)
434정성태2/4/200723534Windows: 15. MIC 환경 구성 - Windows XP와 유사한 보안 설정 [4]
433정성태1/12/200733029Windows: 14. 보호 모드와 필수 무결성 제어(MIC: Mandatory Integrity Control) [3]파일 다운로드1
432정성태1/10/200724087Windows: 13. InitOnceExecuteOnce API 소개 [5]
431정성태1/8/200721783Windows: 12. 비스타는 안전한 윈도우인가? [2]
430정성태1/7/200727713웹: 6. IIS 7 마이그레이션 정리 - Sysnet
427정성태12/30/200618402Team Foundation Server: 14. VS.NET IDE에 통합된 TFS Annotate [1]
425정성태12/29/200622323Windows: 11. Vista IIS 7(Integrated mode)에서의 ASP.NET F5 디버깅 방법
424정성태12/29/200620414기타: 16. 첫걸음 [2]
426정성태12/30/200618866    답변글 기타: 16.1. 예외 발생
420정성태12/27/200623499Windows: 10. Internet Explorer 7.0 호환성 백서 (Word 문서, 1.92MB) [7]파일 다운로드1
419정성태12/25/200625226Windows: 9. VS.NET 2005 원격 디버깅 구성
418정성태12/25/200633321웹: 5. IIS 7에서 클라이언트 측 인증서 사용 시 주의점 [2]
417정성태12/24/200625791Windows: 8. VS.NET 2005에서의 웹 애플리케이션 디버깅 설정
416정성태1/31/200725769오류 유형: 23. MSI 설치 시 로그 파일 생성하는 레지스트리 설정 [3]
415정성태12/31/200629552개발 환경 구성: 20. 인증서 오류 체크 목록
413정성태12/20/200626481VC++: 26. volatile 키워드 [1]파일 다운로드1
412정성태12/17/200630302오류 유형: 22. VS.NET 2005 SP1 설치 도중 오류 [9]
411정성태12/16/200619335오류 유형: 21. TFS SP1 설치 관련 오류 (2) - KB919156 패치 이후 TFS 접근 문제
410정성태12/16/200620650오류 유형: 20. TFS SP1 설치 관련 오류 (1) - KB919156 패치
408정성태12/10/200622840Windows: 7. USB 드라이브 내용 암호화
407정성태12/10/200620434오류 유형: 19. Vista 에서의 VS.NET 2005 로 개발한 어셈블리에 대한 서명 확인 오류
406정성태12/10/200625201Windows: 6. IE 7 검색 공급자 - 영한 사전
403정성태12/6/200632333Windows: 5. Vista 와 웹 인증 등록 서비스의 문제 [5]
402정성태12/11/200623319Windows: 4. Vista 설치 후기 [1]
409정성태12/11/200627332    답변글 Windows: 4.1. Vista 설치 후기 - 두 번째 이야기 [3]
396정성태2/13/200730039오류 유형: 18. "Automatic Updates" 서비스 CPU 100% 점유 현상
... 181  [182]  183  184  185  186  187  188  189  190  191  192  193  194  195  ...