Socket Bind failed (Error:10013, Desc:액세스 권한에 의해 숨겨진 소켓에 액세스를 시도했습니다. )

방법들 

1. port가 사용중인가?

확인방법 : netstat -ao(속도가 느리네)

2. 방화벽, 안티바이러스

검색시 안티바이러스나 방화벽을 확인하라고 했는데 걸리는 부분을 찾을 수 없었음

그래서 방화벽 -> 고급설정 -> 인바운드 규칙 -> 기존에 등록된 프로그램 제거하고 컴퓨터 재부팅하고 다시 프로그램 실행해서 등록하니 정상적으로 동작함

3. 그냥 컴퓨터 재부팅 

office 365 사용시

imex=1 로 Text로 읽지 못할때

https://docs.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/initializing-the-microsoft-excel-driver?tabs=office-2016

 For 32-bit Office on 32-bit Windows or 64-bit Office on 64-bit Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\Excel

For 32-bit Office on 64-bit Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\Excel

ios에서 template 특수화 빌드시 에러나는 경우

프로젝트 진행중 ios빌드중에 BasePacket.h 에서

error: type 'CheckImpl<IsPod<CSimple>::Value>' does not provide a call operator

return impl(*this, value);

라는 에러가 발생하여

template <bool IsPod, typename fake = void> 로 수정해서 처리함

이유에 대해선 찾아봐야 함

빌드 이벤트 최신 상태에서도 이벤트 동작 가능하도록 하기

DisableFastUpToDateCheck 빌드 옵션 추가

.csproj

마지막 라인에 아래 내용 추가

.......

  <PropertyGroup>

    <DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>

  </PropertyGroup>

</Project>

MSSQL 프로시저, 사용자 정의 함수 차이

< 프로시저 >
반환값으로 int 사이즈
insert에서 콜할수 없음
트랙젝션 가능


< 사용자 정의 함수 >
반환값으로 지정가능
insert에서 콜 가능
트랙젝션 불가능

setsockopt SO_RCVTIMEO 윈도우에서 적용하기

이번에 개발하면서 recv 블로킹이 해제될 수 있게 타임아웃이 필요함

소켓 옵션중에
setsockopt so_rcvtimeo
통해서 recv 타임아웃을 설정 할 수 있음

근데 타임아웃이 걸리지 않아 찾아보니

https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-setsockopt
윈도우는 DWORD를 사용해야 함

<윈도우용>
DWORD tv = 1000; //밀리세컨드
setsockopt(c->fd, SOL_SOCKET, SO_RCVTIMEO, (char*)&tv, sizeof(tv));

<그외>
timeval tv = { 0, 10000 }; //seconds, microseconds
setsockopt(c->fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

크래시 발생 원인 - 메시지 처리

사용하던 코어 코드 중에 간헐적으로 크래시가 발생하는 경우 발생

메시지 큐 방식으로 여러 메시지큐에 동일한 메시지를 던진 상태에서
아래와 같은 코드형태로 처리가 되는 중이었음

 1: auto count = ::InterlockedDecrement64(&pMsg->wait_count);
 2: if(count)
 3: {
 4:    WaitForSingleObject(pMsg->Handle);
 5: }
 6: else
 7: {
 8:    Process(pMsg);
 9:    SAFE_DELETE(pMsg);
10: }

크래시가 발생하는 구간은 형광색 구간이었는데
count = 1 인 상태였다

왜 죽었을까?

원인은 컨태스트 스위칭이 발생하면서
A, B 스레드가 있다고 할때
A에서 2라인을 체크 if 문 안으로 진입 컨테스트 스위칭 발생
B에서 9라인 처리
pMsg는 파기된 상태. 다시 컨테스트 스위칭
A 4라인에서 pMsg는 뎅글링 포인트가 되면서 크래시가 발생


어떻게보면 가장 기초적인 실수중에 하나인데 이 문제로 엄청난 스트레스와 코어 코드의 신뢰를 잃는 큰 손실을 봤다