336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

Wireshark 특정 패킷, 필터링 된 패킷만 별개의 파일로 저장



필터 로 필터링된 패킷,


혹은 선택된 패킷 들을 


별개의 pcap 파일로 보내고 싶을때는,





[File] [Export Specified Packets] 






이런 식으로 특정 패킷만 따로 저장 할 수 있다.





pjproject-2.5.5

Programming/C,CPP,CS 2016. 10. 14. 16:16 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

pjproject-2.5.5





pjproject-2.5.5\pjsip-apps\bin\samples\i386-win32-vc8-debug



아주 많은 sample 이 있습니다.






정말 많은 기능이 있네요...................................




'Programming > C,CPP,CS' 카테고리의 다른 글

Jsoncpp 주의 사항  (0) 2016.11.01
OpenSSL x86 Build  (0) 2016.10.28
pjsip Building for Microsoft Windows  (1) 2016.10.12
oRTP  (0) 2016.10.11
log4cxx dll build  (1) 2016.09.27

pjsip Building for Microsoft Windows

Programming/C,CPP,CS 2016. 10. 12. 14:10 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

pjsip Building for Microsoft Windows


출처 : https://trac.pjsip.org/repos/wiki/Getting-Started/Windows





Build Preparation for Windows

  1. Get the source code, if you haven't already.
  2. It is important that you create a config_site.h as described in Build Preparation

Building the Projects

Follow the steps below to build the libraries/application using Visual Studio:

  1. For Visual Studio 6/2002/2003: open pjproject.dsw workspace file. (No longer supported since pjsip 2.0)
  2. For Visual Studio 8 (VS 2005): open pjproject-vs8.sln solution file.
  3. For Visual Studio 9 (VS 2008): open pjproject-vs8.sln solution file. One-time conversion of projects to VS 2008 format will done automatically.
  4. For Visual Studio 11 (VS 2012): open pjproject-vs8.sln solution file. One-time conversion of projects to VS 2012 format will done automatically.
    1. Warnings about Windows Mobile projects/configurations can be safely ignored, VS 2012 does not support Windows Mobile
    2. Additional tips from pjsip mailing list
  5. Set pjsua as Active or Startup Project.
  6. Set Win32 as the platform.
  7. Select Debug or Release build as appropriate.
  8. Build the project. This will build pjsua application and all libraries needed by pjsua.
  9. After successful build, the pjsua application will be placed in pjsip-apps/bin directory, and the libraries in lib directory under each projects.

To build the samples:

  1. (Still using the same workspace)
  2. Set samples project as Active Project
  3. Select Debug or Release build as appropriate. See Visual Studio Build Configuration page for explanation of each provided build configuration
  4. Build the project. This will build all sample applications and all libraries needed.
  5. After successful build, the sample applications will be placed in pjsip-apps/bin/samples directory, and the libraries in lib directory under each projects.



'Programming > C,CPP,CS' 카테고리의 다른 글

OpenSSL x86 Build  (0) 2016.10.28
pjproject-2.5.5  (0) 2016.10.14
oRTP  (0) 2016.10.11
log4cxx dll build  (1) 2016.09.27
OpenSSL x64 Build  (0) 2016.09.27

oRTP

Programming/C,CPP,CS 2016. 10. 11. 16:47 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

oRTP 참고자료 : 



http://blog.daum.net/knightofelf/184



http://download.savannah.gnu.org/releases/linphone/ortp/docs/


http://www.linphone.org/eng/documentation/dev/ortp.html


http://icapeople.epfl.ch/thiran/CoursED/RTP.pdf


http://vip.cs.utsa.edu/classes/cs6593f2002/laboratories/rtpInfo/Example1.html


'Programming > C,CPP,CS' 카테고리의 다른 글

pjproject-2.5.5  (0) 2016.10.14
pjsip Building for Microsoft Windows  (1) 2016.10.12
log4cxx dll build  (1) 2016.09.27
OpenSSL x64 Build  (0) 2016.09.27
debug_crt_heap table  (0) 2016.09.19

RTP Payload Type 참고자료

CiscoNetwork 2016. 10. 11. 12:04 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

RTP Payload Type 참고자료



https://tools.ietf.org/html/rfc1890


      PT         encoding      audio/video    clock rate    channels
                 name          (A/V)          (Hz)          (audio)
      _______________________________________________________________
      0          PCMU          A              8000          1
      1          1016          A              8000          1
      2          G721          A              8000          1
      3          GSM           A              8000          1
      4          unassigned    A              8000          1
      5          DVI4          A              8000          1
      6          DVI4          A              16000         1
      7          LPC           A              8000          1
      8          PCMA          A              8000          1
      9          G722          A              8000          1
      10         L16           A              44100         2
      11         L16           A              44100         1
      12         unassigned    A
      13         unassigned    A
      14         MPA           A              90000        (see text)
      15         G728          A              8000          1
      16--23     unassigned    A
      24         unassigned    V
      25         CelB          V              90000
      26         JPEG          V              90000
      27         unassigned    V
      28         nv            V              90000
      29         unassigned    V
      30         unassigned    V
      31         H261          V              90000
      32         MPV           V              90000
      33         MP2T          AV             90000
      34--71     unassigned    ?
      72--76     reserved      N/A            N/A           N/A
      77--95     unassigned    ?
      96--127    dynamic       ?

   Table 2: Payload types (PT) for standard audio and video encodings

https://tools.ietf.org/html/rfc3551#page-32


               PT   encoding    media type  clock rate   channels
                    name                    (Hz)
               ___________________________________________________
               0    PCMU        A            8,000       1
               1    reserved    A
               2    reserved    A
               3    GSM         A            8,000       1
               4    G723        A            8,000       1
               5    DVI4        A            8,000       1
               6    DVI4        A           16,000       1
               7    LPC         A            8,000       1
               8    PCMA        A            8,000       1
               9    G722        A            8,000       1
               10   L16         A           44,100       2
               11   L16         A           44,100       1
               12   QCELP       A            8,000       1
               13   CN          A            8,000       1
               14   MPA         A           90,000       (see text)
               15   G728        A            8,000       1
               16   DVI4        A           11,025       1
               17   DVI4        A           22,050       1
               18   G729        A            8,000       1
               19   reserved    A
               20   unassigned  A
               21   unassigned  A
               22   unassigned  A
               23   unassigned  A
               dyn  G726-40     A            8,000       1
               dyn  G726-32     A            8,000       1
               dyn  G726-24     A            8,000       1
               dyn  G726-16     A            8,000       1
               dyn  G729D       A            8,000       1
               dyn  G729E       A            8,000       1
               dyn  GSM-EFR     A            8,000       1
               dyn  L8          A            var.        var.
               dyn  RED         A                        (see text)
               dyn  VDVI        A            var.        1

               Table 4: Payload types (PT) for audio encodings





http://www.ktword.co.kr/abbr_view.php?m_temp1=3394

     - 오디오 타입 번호 例)
        . 0 -> G.711 PCM(mu-law), 샘플링주파수 8000 Hz
        . 3 -> GSM,               샘플링주파수 8000 Hz
        . 4 -> G.723,             샘플링주파수 8000 Hz
        . 6 -> DVI4 (ADPCM),      샘플링주파수 16000 Hz
        . 7 -> LPC,               샘플링주파수 8000 Hz
        . 8 -> G.711 PCM(A-Law)   샘플링주파수 8000 Hz
        . 9 -> G.722,             샘플링주파수 8000 Hz
        . 14 -> MPEG 오디오,      샘플링주파수 90000 Hz
        . 15 -> G.728,            샘플링주파수 8000 Hz

https://tools.ietf.org/html/rfc1890


4. Audio

4.1 Encoding-Independent Recommendations

For applications which send no packets during silence, the first packet of a talkspurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero. The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.) If multiple audio channels are used, channels are numbered left-to- right, starting at one. In RTP audio packets, information from lower-numbered channels precedes that from higher-numbered channels. For more than two channels, the convention followed by the AIFF-C audio interchange format should be followed [1], using the following notation: l left r right c center S surround F front R rear channels description channel 1 2 3 4 5 6 ___________________________________________________________ 2 stereo l r 3 l r c 4 quadrophonic Fl Fr Rl Rr 4 l c r S 5 Fl Fr Fc Sl Sr 6 l lc c r rc S



https://tools.ietf.org/html/rfc3551#page-32


4.4 Audio Encodings

encoding sample/frame bits/sample ms/frame ____________________________________________________ 1016 frame N/A 30 DVI4 sample 4 G721 sample 4 G722 sample 8 G728 frame N/A 2.5 GSM frame N/A 20 L8 sample 8 L16 sample 16 LPC frame N/A 20 MPA frame N/A PCMA sample 8 PCMU sample 8 VDVI sample var. Table 1: Properties of Audio Encodings

4.5 Audio Encodings

name of sampling default encoding sample/frame bits/sample rate ms/frame ms/packet __________________________________________________________________ DVI4 sample 4 var. 20 G722 sample 8 16,000 20 G723 frame N/A 8,000 30 30 G726-40 sample 5 8,000 20 G726-32 sample 4 8,000 20 G726-24 sample 3 8,000 20 G726-16 sample 2 8,000 20 G728 frame N/A 8,000 2.5 20 G729 frame N/A 8,000 10 20 G729D frame N/A 8,000 10 20 G729E frame N/A 8,000 10 20 GSM frame N/A 8,000 20 20 GSM-EFR frame N/A 8,000 20 20 L8 sample 8 var. 20 L16 sample 16 var. 20 LPC frame N/A 8,000 20 20 MPA frame N/A var. var. PCMA sample 8 var. 20 PCMU sample 8 var. 20 QCELP frame N/A 8,000 20 20 VDVI sample var. var. 20 Table 1: Properties of Audio Encodings (N/A: not applicable; var.: variable)


RTP Data Transfer Protocol

CiscoNetwork 2016. 10. 11. 11:56 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

출처 : https://tools.ietf.org/html/rfc3550#page-13




RTP Protocol




5. RTP Data Transfer Protocol

5.1 RTP Fixed Header Fields

The RTP header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted by a mixer. The fields have the following meaning: version (V): 2 bits This field identifies the version of RTP. The version defined by this specification is two (2). (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol initially implemented in the "vat" audio tool.) padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit. extension (X): 1 bit If the extension bit is set, the fixed header MUST be followed by exactly one header extension, with a format defined in Section 5.3.1. CSRC count (CC): 4 bits The CSRC count contains the number of CSRC identifiers that follow the fixed header.
   marker (M): 1 bit
      The interpretation of the marker is defined by a profile.  It is
      intended to allow significant events such as frame boundaries to
      be marked in the packet stream.  A profile MAY define additional
      marker bits or specify that there is no marker bit by changing the
      number of bits in the payload type field (see Section 5.3).

   payload type (PT): 7 bits
      This field identifies the format of the RTP payload and determines
      its interpretation by the application.  A profile MAY specify a
      default static mapping of payload type codes to payload formats.
      Additional payload type codes MAY be defined dynamically through
      non-RTP means (see Section 3).  A set of default mappings for
      audio and video is specified in the companion RFC 3551 [1].  An
      RTP source MAY change the payload type during a session, but this
      field SHOULD NOT be used for multiplexing separate media streams
      (see Section 5.2).

      A receiver MUST ignore packets with payload types that it does not
      understand.

   sequence number: 16 bits
      The sequence number increments by one for each RTP data packet
      sent, and may be used by the receiver to detect packet loss and to
      restore packet sequence.  The initial value of the sequence number
      SHOULD be random (unpredictable) to make known-plaintext attacks
      on encryption more difficult, even if the source itself does not
      encrypt according to the method in Section 9.1, because the
      packets may flow through a translator that does.  Techniques for
      choosing unpredictable numbers are discussed in [17].

   timestamp: 32 bits
      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations (see Section 6.4.1).  The
      resolution of the clock MUST be sufficient for the desired
      synchronization accuracy and for measuring packet arrival jitter
      (one tick per video frame is typically not sufficient).  The clock
      frequency is dependent on the format of data carried as payload
      and is specified statically in the profile or payload format
      specification that defines the format, or MAY be specified
      dynamically for payload formats defined through non-RTP means.  If
      RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio
      the timestamp clock would likely increment by one for each
      sampling period.  If an audio application reads blocks covering

      160 sampling periods from the input device, the timestamp would be
      increased by 160 for each such block, regardless of whether the
      block is transmitted in a packet or dropped as silent.

      The initial value of the timestamp SHOULD be random, as for the
      sequence number.  Several consecutive RTP packets will have equal
      timestamps if they are (logically) generated at once, e.g., belong
      to the same video frame.  Consecutive RTP packets MAY contain
      timestamps that are not monotonic if the data is not transmitted
      in the order it was sampled, as in the case of MPEG interpolated
      video frames.  (The sequence numbers of the packets as transmitted
      will still be monotonic.)

      RTP timestamps from different media streams may advance at
      different rates and usually have independent, random offsets.
      Therefore, although these timestamps are sufficient to reconstruct
      the timing of a single stream, directly comparing RTP timestamps
      from different media is not effective for synchronization.
      Instead, for each medium the RTP timestamp is related to the
      sampling instant by pairing it with a timestamp from a reference
      clock (wallclock) that represents the time when the data
      corresponding to the RTP timestamp was sampled.  The reference
      clock is shared by all media to be synchronized.  The timestamp
      pairs are not transmitted in every data packet, but at a lower
      rate in RTCP SR packets as described in Section 6.4.

      The sampling instant is chosen as the point of reference for the
      RTP timestamp because it is known to the transmitting endpoint and
      has a common definition for all media, independent of encoding
      delays or other processing.  The purpose is to allow synchronized
      presentation of all media sampled at the same time.

      Applications transmitting stored data rather than data sampled in
      real time typically use a virtual presentation timeline derived
      from wallclock time to determine when the next frame or other unit
      of each medium in the stored data should be presented.  In this
      case, the RTP timestamp would reflect the presentation time for
      each unit.  That is, the RTP timestamp for each unit would be
      related to the wallclock time at which the unit becomes current on
      the virtual presentation timeline.  Actual presentation occurs
      some time later as determined by the receiver.

      An example describing live audio narration of prerecorded video
      illustrates the significance of choosing the sampling instant as
      the reference point.  In this scenario, the video would be
      presented locally for the narrator to view and would be
      simultaneously transmitted using RTP.  The "sampling instant" of a
      video frame transmitted in RTP would be established by referencing
      its timestamp to the wallclock time when that video frame was
      presented to the narrator.  The sampling instant for the audio RTP
      packets containing the narrator's speech would be established by
      referencing the same wallclock time when the audio was sampled.
      The audio and video may even be transmitted by different hosts if
      the reference clocks on the two hosts are synchronized by some
      means such as NTP.  A receiver can then synchronize presentation
      of the audio and video packets by relating their RTP timestamps
      using the timestamp pairs in RTCP SR packets.

   SSRC: 32 bits
      The SSRC field identifies the synchronization source.  This
      identifier SHOULD be chosen randomly, with the intent that no two
      synchronization sources within the same RTP session will have the
      same SSRC identifier.  An example algorithm for generating a
      random identifier is presented in Appendix A.6.  Although the
      probability of multiple sources choosing the same identifier is
      low, all RTP implementations must be prepared to detect and
      resolve collisions.  Section 8 describes the probability of
      collision along with a mechanism for resolving collisions and
      detecting RTP-level forwarding loops based on the uniqueness of
      the SSRC identifier.  If a source changes its source transport
      address, it must also choose a new SSRC identifier to avoid being
      interpreted as a looped source (see Section 8.2).

   CSRC list: 0 to 15 items, 32 bits each
      The CSRC list identifies the contributing sources for the payload
      contained in this packet.  The number of identifiers is given by
      the CC field.  If there are more than 15 contributing sources,
      only 15 can be identified.  CSRC identifiers are inserted by
      mixers (see Section 7.1), using the SSRC identifiers of
      contributing sources.  For example, for audio packets the SSRC
      identifiers of all sources that were mixed together to create a
      packet are listed, allowing correct talker indication at the
      receiver.

제어비트  : 16 비트
     - Ver (버젼)      : 2 비트
        . 현재 RTP 버젼은, 2 (RFC 3550)
     - P (padding)     : 1 비트
        . 1 이면 실제 유료부하 끝에 덧붙여진 패딩 데이터 있음
        . 응용프로그램이 32 비트 같은 정수배 단위로 RTP 패킷 페이로드 구성을 위함
     - X (extension)   : 1 비트
        . 1 이면 가변길이 헤더 확장(Extension Header)이 있음을 나타냄
     - CC (CSRC Count) : 4 비트
        . 기본 헤더 바로 뒤에 나타나는 CSRC(Countributing SouRCe) ID의 갯수
        . 여러 미디어가 합성되는 경우에, 그 개수를 CC로써 나타내고,
          모두의 기준 동기를 맞추려면 SRRC ID로써 이를 나타냄
     - M (Marker)      : 1 비트
        . 이벤트 발생이 시작되었음을 알림

  ㅇ 유료부하 타입(Payload type) : (7 비트)  오디오/비디오 인코딩(코덱) 종류
     - 오디오 타입 번호 例)
        . 0 -> G.711 PCM(mu-law), 샘플링주파수 8000 Hz
        . 3 -> GSM,               샘플링주파수 8000 Hz
        . 4 -> G.723,             샘플링주파수 8000 Hz
        . 6 -> DVI4 (ADPCM),      샘플링주파수 16000 Hz
        . 7 -> LPC,               샘플링주파수 8000 Hz
        . 8 -> G.711 PCM(A-Law)   샘플링주파수 8000 Hz
        . 9 -> G.722,             샘플링주파수 8000 Hz
        . 14 -> MPEG 오디오,      샘플링주파수 90000 Hz
        . 15 -> G.728,            샘플링주파수 8000 Hz
     - 비디오 타입 번호 例)
        . 26 -> 화상 JPEG, 31 -> H.261, 32 -> MPEG-1 또는 MPEG-2 비디오, 
          33 -> MPEG-2 TS 등
     - 기타 임의 지정 가능(dynamic payload type) : 96~127

     * RTP유료부하 유형(Payload type) 표준 목록 ☞ IANA RTP Parameters
        . RFC 3551에서 오디오 신호/비디오 신호인코딩 방법,샘플링 주파수 등이 기술됨

  ㅇ 순서번호(Sequence number) : (16 비트)
     - 패킷 손실 검출 및 순서 재구성 
        . 초기값은 랜덤이고, 매 패킷 마다 1씩 증가
           .. 수신측은 패킷 재전송 요청 보다는 패킷 손실 검출 및 뒤바뀐 순서 복구를 위함

  ㅇ 타임스탬프(Timestamp) : (32 비트)
     - RTP 스트림 내 각 RTP 패킷샘플링시간관계를 나타냄
        . 랜덤한 초기값부터 시작하며, 통상적으로 카운터에 의해 1씩 증가시킴

     - 타임스탬프 간격은 유료부하 유형에 따라 정해진 샘플링 간격을 기준 
        . 대부분의 오디오 RTP 패킷의 경우 => 1 패킷 당 디폴트 시간 간격을 20 ms으로 함
           .. 例) G.711 (PCM A-Law) 오디오 페이로드 패킷 크기 
                    = (유료부하 코덱 데이터율) x (1 패킷시간 간격)
                    = (64 kbps G.711 코덱) x (20 ms)
                    = (8000 samples x 8 bits)/sec x (0.02 sec)
                    = 160 바이트

     - 타임스탬프 값의 연속성 의미 구분
        . 例1) 일련의 패킷들의 타임스탬프 값이 `같은` 경우  
           .. 특정 비디오 장면이 같은 시간샘플링되었음을 의미
        . 例2) 일련의 패킷들의 타임스탬프 값이 `단순 증가하지 않는` 경우
           .. MPEG 화면 픽처 처럼 시간 순서가 어긋나며 전후 화면으로부터 예측되었음을 의미
        . 例3) 일련의 패킷들의 타임스탬프 값이 `연속 증가`되는 번호 순서를 갖음
           .. 오디오 패킷 흐름일 경우 등

  ㅇ 동기 발신 식별자 (SSRC ID, Synchronization SouRCe ID) : (32 비트)
     - 원래의 정보 스트림에 대한 식별 
        . 하나의 RTP 세션 내에서는, 
           .. 각각의 발송지는 무작위 SSRC ID로 나타내고, 
           .. 타 발송지와의 구별을 위해 중복되지 않아야 함
        . 여러 미디어가 혼합되어 있으면, 
           .. SSRC는 일종의 기준 역할이 가능함

     * RTP 세션 이란? 
        . RTP를 통해 상호 통신하는 참가자들 간에 형성된 논리적 연결 상태
        . RTP 세션에서 목적지 확인은, 
           .. 1개의 IP 주소 및 1쌍의 RTP/RTCP 번호로 식별됨
           .. 이때 IP 주소멀티캐스트 주소일 수도 있음
        . 만일, 여러 미디어믹서에서 혼합되면, 그 믹서에 대한 SSRC ID를 갖게됨

  ㅇ 기여 발신 식별자 (CSRC ID, Contributor SouRCe ID) 목록 : (32 비트) 1 이상 가변 갯수
     - 믹서(Mixer)를 통해 혼합되어 단일의 정보열로 되면, 원래의 각각에 대한 식별 역할
        . 여러 미디어가 혼합되면, CC(CSRC Count:4 비트)에 총 개수를 지정하고, 
        . SSRC 이외 추가된 스트림들에 대한 식별자를 CSRC ID 값으로 함

     * 만일, 하나의 미디어 소스 만 있다면, 
        . CC=1 이되고, RTP 헤더 길이는 12 바이트(기본헤더 길이)가 됨
        . 결국, SSRC ID가 하나의 값을 갖고, CSRC ID 목록은 비어있게 됨

  ※ [참고_웹] ☞ RTP의 이해


336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

링커 도구 경고 LNK4098


LINK : warning LNK4098: 'LIBCMT' defaultlib가 다른 라이브러리와 충돌합니다. /NODEFAULTLIB:library를 사용하십시오.





호환되지 않는 라이브러리에 링크하려고 했습니다.

System_CAPS_note참고

런타임 라이브러리에는 여러 형식이 혼합 사용되지 않도록 하는 지시문이 들어 있는데  여러 형식이나 디버그/비디버그 버전의 런타임 라이브러리를 동일한 프로그램에서 사용하려고 하면 이 경고가 발생합니다.  예를 들어, 어떤 종류의 런타임 라이브러리를 사용하는 파일을 컴파일하고 다른 종류의 런타임 라이브러리를 사용하는 파일을 컴파일한 다음(예: 단일 스레드 라이브러리와 다중 스레드 라이브러리) 이 둘을 링크시키려고 하면 이 경고가 발생합니다.  동일한 런타임 라이브러리를 사용하는 소스 파일을 컴파일해야 합니다.  자세한 내용은 런타임 라이브러리 사용(/MD/MT,/LD) 컴파일러 옵션을 참조하십시오.  

링커의 /VERBOSE:LIB 스위치를 사용하여 링커가 검색 중인 라이브러리를 확인할 수 있습니다.  예를 들어, LNK4098이 발생하여 단일 스레드된 비디버그 런타임 라이브러리를 사용하는 실행 파일을 만들려는 경우에는 /VERBOSE:LIB 옵션을 사용하여 링커에서 검색 중인 라이브러리를 확인하십시오.  링커는 검색한 라이브러리로 LIBC.lib를 출력하며 LIBCMT.lib, MSVCRT.lib, LIBCD.lib, LIBCMTD.lib 또는 MSVCRTD.lib는 출력하지 않습니다.  무시할 각 라이브러리에 대해 /NODEFAULTLIB를 사용하여 링커가 잘못된 런타임 라이브러리를 무시하도록 할 수 있습니다.  

다음 표는 사용할 런타임 라이브러리에 따라 무시해야 하는 라이브러리를 보여 줍니다.

사용할 런타임 라이브러리

무시해야 하는 라이브러리

단일 스레드(libc.lib)

libcmt.lib, msvcrt.lib, libcd.lib, libcmtd.lib, msvcrtd.lib

다중 스레드(libcmt.lib)

libc.lib, msvcrt.lib, libcd.lib, libcmtd.lib, msvcrtd.lib

DLL을 사용하는 다중 스레드(msvcrt.lib)

libc.lib, libcmt.lib, libcd.lib, libcmtd.lib, msvcrtd.lib

디버그 단일 스레드(libcd.lib)

libc.lib, libcmt.lib, msvcrt.lib, libcmtd.lib, msvcrtd.lib

디버그 다중 스레드(libcmtd.lib)

libc.lib, libcmt.lib, msvcrt.lib, libcd.lib, msvcrtd.lib

DLL을 사용하는 디버그 다중 스레드(msvcrtd.lib)

libc.lib, libcmt.lib, msvcrt.lib, libcd.lib, libcmtd.lib






1. DLL을 사용하는 다중 스레드(msvcrt.lib) 일경우








336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

공유 DLL에서 MFC 사용 VS 정적 라이브러리에서 MFC 사용 


이 둘의 차이점?










공유 DLL에서 MFC 사용(Use MFC in a Shared DLL) : 응용프로그램 배포 시 mfc**.dll 파일을 함께 배포.
정적 DLL에서 MFC 사용(Use MFC in a Static Library) : 응용프로그램의 실행 파일에 mfc**.dll 이 포함되어 배포되기 때문에 응용프로그램만 배포.













기본적으로 "Use MFC in a Shared DLL" 가 설정되어 있습니다. 이 설정은 현재 개발중인 프로그램이 필요로 하는 라이브러리를 기본적으로 제공되는 DLL에서 참조하여 사용하겠다는 뜻입니다. 따라서 이 모드로 컴파일을 하여 실행파일을 배포하려면, 해당 컴파일에 Visual C++가 설치되어 있거나 다음과 같은 DLL이 있어야 합니다. mfc42d.dll, mfco42d.dll, msvcirtd.dll, msvcrtd.dll 물론 이 네 종류의 DLL 파일이 모두 있어야 하는 것은 아닙니다. 개발된 프로그램의 성격에 따라서 이 중 한 개정도가 필요 없을 때도 있습니다.

이 DLL은 이름이 mfc42d.dll과 같이 d로 끝나는데, 이 d는 "Debug" 의 약자로 생각하시면 됩니다. 이 파일들은 윈도우 시스템이 설치된 폴더의 "system32" 폴더 아래에 있습니다. 필요하다면, 해당 폴더에서 이 dll들을 복사해서 실행파일을 배포할 때 같이 배포하면 됩니다. 사실, 어떤 경우에 보면, 실행파일은 크기가 얼마되지 않는데 같이 붙어 다니는 dll의 사이즈가 엄청 큰 이상한 경우가 발생 하기도 합니다."Use MFC in a Static Library" 로 설정되어 있는 경우 컴파일을 하고 나서 실행파일을 배포할 때 별도의 dll을 같이 제공할 필요가 없습니다. 실행파일만 제공하면 되죠. 하지만, 이 방법은 별도의 dll이 없는 반면에 실행 파일의 사이즈가 좀 크다는 단점이 있습니다.
 
이 두 가지를 놓고 볼 때, 다음과 같이 일반적인 결론을 내릴 수 있습니다. 단순히 하나의 실행파일을 가지는 프로그램인 경우, "Use MFC in a Static Library" 를 사용해서 컴파일 하는 것이 비교적 유리하고 여러 개의 실행파일과 또는 dll이 사용되는 프로그램인 경우 각각의 실행파일 사이즈를 줄일 수 있는 "Use MFC in a Shared DLL"을 사용하는 것이 더 유리하다고 할 수 있습니다. 따라서 개발자가 이 두 가지 상황을 잘 판단해서 사용하면 될 것 같습니다.





  배포 시 응용프로그램만 배포하는게 관리하기도 편하고 오작동의 가능성도 적기 때문에 "정적 DLL 에서 MFC 사용" 으로 프로젝트를 설정하여 개발하게 된다.

  응용프로그램이 DLL 일 경우 위와 같이 설정하면 컴파일 시 다음과 같은 오류 메시지가 발생한다.
fatal error C1189: #error :  Please use the /MD switch for _AFXDLL builds

다음과 같이 설정해 주자.


1. 전처리기 정의

C/C++ → 전처리기 → 전처리기 정의
"_AFXDLL" 추가




2. 코드 생성

C/C++ → 코드 생성 → 런타임 라이브러리
Debug 모드일 경우    : "다중 스레드 디버그 DLL(/MDd)" 설정
Release 모드일 경우 :  "다중 스레드 DLL(/MD)" 설정







참고 : http://six605.tistory.com/466

참고 : https://social.msdn.microsoft.com/Forums/ko-KR/ba6bfe1c-8f80-45ea-809b-ec543dd6dc31/-dll-mfc-vs-mfc-?forum=asppnetko



Hiredis Subscribe/Publish with CWinThread

Programming/Redis 2016. 10. 5. 14:01 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

Hiredis Subscribe/Publish



CWinThread 를 이용한 구현




struct event_base *base = event_base_new();

class CRedisConnect : public CWinThread
{
public:
	redisAsyncContext *c;
	// CWinThread extends
	virtual BOOL InitInstance();
	virtual int Run();
};

BOOL CRedisConnect::InitInstance()
{
	return TRUE;
}

int CRedisConnect::Run()
{
	c = redisAsyncConnect(redisServerIP, redisServerPort);
	if (c->err) {
		/* Let *c leak for now... */
		return 1;
	}
	redisLibeventAttach(c, base);

	int re2 = redisAsyncCommand(c, getCallback, NULL, "SUBSCRIBE foo");

	event_base_dispatch(base);

	return (0);
}



void getCallback(redisAsyncContext *c, void *r, void *privdata) {

	redisReply *reply = (redisReply *)r;
	if (reply == NULL)
	{
		LOG4CXX_DEBUG(g_log, "Subcribe reply == NULL");
	}
	// reply->type
	// #define REDIS_REPLY_STRING 1
	// #define REDIS_REPLY_ARRAY 2
	// #define REDIS_REPLY_INTEGER 3
	// #define REDIS_REPLY_NIL 4
	// #define REDIS_REPLY_STATUS 5
	// #define REDIS_REPLY_ERROR 6
	else if (reply->type == REDIS_REPLY_ERROR)
	{
		LOG4CXX_DEBUG(g_log, "Subcribe reply type == REDIS_REPLY_ERROR");
	}
	else if (reply->type == REDIS_REPLY_ARRAY)
	{
		LOG4CXX_DEBUG(g_log, "reply->elements == " << reply->elements);
		LOG4CXX_DEBUG(g_log, "reply->len == " << reply->len);
		for (int i = 0; i < reply->elements; i++)
		{
			if (reply->element[i]->str != NULL)
			LOG4CXX_DEBUG(g_log, "Subcribe reply array [" << i << "] == " << reply->element[i]->str);			
		}		
	}
	else
	{
		LOG4CXX_DEBUG(g_log, "getCallback reply str : " << reply->str);
	}
}

'Programming > Redis' 카테고리의 다른 글

Hiredis SMEMBERS 활용  (0) 2017.01.24
Redis Client Connect Test  (0) 2016.10.26
How to use Pub/sub with hiredis in C++?  (0) 2016.09.29
hiredis fatal error C1853:  (0) 2016.09.29
hiredis MFC import Visual Studio 2013  (0) 2016.09.28

How to use Pub/sub with hiredis in C++?

Programming/Redis 2016. 9. 29. 14:06 Posted by TanSanC
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

example for pub/sub



https://github.com/redis/hiredis/issues/55 aluiken commented on Mar 2, 2012




void onMessage(redisAsyncContext *c, void *reply, void *privdata) {
    redisReply *r = reply;
    if (reply == NULL) return;

    if (r->type == REDIS_REPLY_ARRAY) {
        for (int j = 0; j < r->elements; j++) {
            printf("%u) %s\n", j, r->element[j]->str);
        }
    }
}

int main (int argc, char **argv) {
    signal(SIGPIPE, SIG_IGN);
    struct event_base *base = event_base_new();

    redisAsyncContext *c = redisAsyncConnect("127.0.0.1", 6379);
    if (c->err) {
        printf("error: %s\n", c->errstr);
        return 1;
    }

    redisLibeventAttach(c, base);
    redisAsyncCommand(c, onMessage, NULL, "SUBSCRIBE testtopic");
    event_base_dispatch(base);
    return 0;
}

'Programming > Redis' 카테고리의 다른 글

Redis Client Connect Test  (0) 2016.10.26
Hiredis Subscribe/Publish with CWinThread  (0) 2016.10.05
hiredis fatal error C1853:  (0) 2016.09.29
hiredis MFC import Visual Studio 2013  (0) 2016.09.28
Windows7 Redis 설치 및 실행  (0) 2016.09.27