| 일 | 월 | 화 | 수 | 목 | 금 | 토 | 
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | 
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | 
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | 
| 30 | 
- WPF
 - c# api호출
 - 업비트 c#
 - 업비트 API
 - c# maui
 - maui
 - c# restapi
 - 업비트 차트
 - upbit
 - 나만의 사이트모음집
 - 즐겨찾기
 - c# 라이브 차트
 - 북마크
 - Prism
 - c# 업비트 api키 목록
 - 업비트
 - 차트
 - Upbit API
 - c# restapi 호출
 - 라이브 차트
 - c# websocket
 - c# 업비트
 - C#
 - Chart
 - c# 차트
 - XAML
 
- Today
 
- Total
 
목록전체 글 (130)
하아찡
매번 그냥 이름이 헷갈린다.오버로딩.. 오버라이딩...왜 앞에 두개가 똑같아서 일단 오버라이딩부터 보자.오버라이딩은 Base클래스에서 Derived클래스에서 오버라이딩할 때는 "함수명, 매개변수, 리턴타입"이 동일해야합니다.다른말로하면 부모클래스에서 자식클래스에서 오버라이딩할 때는 "함수명, 매개변수, 리턴타입"이 동일해야합니다.또 다른말로하면 기본클래스에서 파생클래스에서 오버라이딩할 때는 "함수명, 매개변수, 리턴타입"이 동일해야합니다. 그래서 어디서 쓰냐?상속받은 메소드를 재정의해서 사용을 하게됩니다.기존에 상속받아서 쓰던 메소드가 있었는데 해당 메소드를 상속받은 클래스에서 다르게 사용하게될때 새롭게 재정의 한다고 생각하면 됩니니다. 예시를 보자면#include #include class Base..
포인터를 배우면서 같이 배우게 되는 레퍼런스(참조자)는 참 알쏭 달쏭한 친구죠. 결과부터 말하자면제가생각하는 레퍼런스를 가장쉽게 설명하는방법은 "친구의 별명" 이라고 생각합니다. 자 여기서 왜 친구의 별명이라고 설명을 했는지를 알고 넘어가야하죠.만약 우리가 A라는 친구를 "똥쟁이" 라고 별명을 지었어요.그러면 우리는 "똥쟁이"를 부르면 A를 부르는걸 알고있죠? 이렇게 간단하게 생각하면 됩니다. 하지만 우리가 공부를 하는데 있어서 간단하게만 알고 넘어갈수도 있지만, 좀 더 알고싶은데? 라고 생각하신다면 더 읽어보셔도 되겠습니다. 일단 기본적으로 "포인터는 메모리상에 남게되고, 참조자는 메모리에 남을수도 있다." 라는 말이 있습니다.그러면 구체적으로 뭐가 다른지를 다시 확인을 하고 넘어가야겠죠. 포인터는 주..
프로그램을 배우면 거의 처음부터 나오는 변수는 무엇일까? 말 뜻 그대로 보자면 변하는 수입니다.하지만 여기서 우리는 프로그램을 공하는 입장에서 더 풀어서 적어보자면, 변하는 수를 저장하는 공간 입니다. 자 여기서 변하는 수? 오케이 공간? 오케이 근데 어따씀?처음 공부를 하면 도대체 어디서 써야할지 하나도 감이 안옵니다. 처음 공부할땐 간단하게 생각합니다. 일단 다 만들고 봐요. 그러고나서 점점 하다보면 비효율 적이다 생각이 들때 다시한번 생각해보면 변수를 꼭 필요한 곳에서만 사용하게 됩니다.간단하게 예를 들어보겠습니다.예를들어 "50이라는 숫자를 저장하고싶고, 100이라는 숫자를 저장하고 싶어" 라고 했을때 50이라는 숫자와 100이라는 숫자를 동시에 가지고 있어야하는 상황입니다. 이럴땐 변수를 두개를..
이전에는 TCP 흐름제어를 테스트해봤는데UDP는 흐름제어가 없다고 배웠다. 그러면 흐름제어가 없을경우 어떻게 될까?일단 테스트를 해본당. 첫번째, TCP처럼 일정이상 데이터가 쌓이게되면 멈출까?TCP기준으론 서버리시브를 일정시간 멈춰두고, 클라이언트에서 일정이상 데이터를 보낼경우 더이상 데이터를 보내지 않았는데.UDP에선 서버 리시브를 일정시간 멈춰두고, 클라이언트에서 무수히 데이터를 보냈는데 멈추는 경우가 없었습니다.해당 테스트는 해보고 넘어가서 사진이 없습니다. ㅠㅠ 두번째, 데이터는 제대로 들어올까?테스트환경은 이러합니다.클라이언트쪽에서 서버측으로 데이터를 계속 보냅니다.서버측에선 클라이언트 데이터를 계속 받습니다.무수히 빠르게 데이터를 주고 받는과정에서 과연 데이터가 정상적으로 들어왔는지를 확인..
이전에는 Boundary를 확인해보고 해결방법도 생각해봤는데TCP에서 흐름을 자동으로 제어해준다? 라는게 사실 와닿지가 않음. 눈으로 볼 수 있으면 좋은데보이면 어떻게 흐름이 제어가 되고있는지도 확인을 해볼까해서 이것저것테스트하는중. 테스트 과정은 이러합니다클라이언트에서 SendBuffer 를 왕창 채워봅니다. -> 일정시간을 기다린다음 -> 서버측에서 리시브를 합니다 -> 서버측에서 리시브를 받는동안에도 클라이언트는 SendBuffer 에 왕창데이터를 채워봅니다. -> 이과정에서 클라이언트 쪽에서 Send가 멈추는지를 확인해봅니다. 위 gif를 보면 왼쪽은 클라이언트 / 오른쪽은 서버 입니다.(중간에 서버측 값이 100이상으로 변경된건 캡처를 잠시 멈췄다가 다시했습니다.)왼쪽 클라이언트가 Send를 빠..
소켓통신을 공부하다보니 TCP는 전송 순서와 손실을 보장주지만, 데이터 사이의 경계가 없다.데이터 사이의 경계가 없는게 무엇일까?내가 클라이언트에서 5Byte를 10000번을 보냈는데서버측에서 한번에 받는 리시브 버퍼가 99Byte이면 한번씩 주거니 받거니할땐 상관이 없겠지만클라이언트 쪽에서 데이터를 계속 보내고있는데 서버측에서 리시브를 하지않는경우 커널쪽 리시브 버퍼쪽에 데이터가 쌓이게 됩니다.만약 해당 데이터가 20번 반복해서 100Byte가 버퍼에 차있을경우, TCP 통신의 경우 Boundary가 없기 때문에 한개의 데이터 5Byte를 읽어오는게 아닌 99Byte를 읽어오게 됩니다.위 과정에서 데이터가 잘리게 됩니다. 테스트 과정은 0부터 9999까지 정수를 보내는 과정 일부 메모리를 캡쳐했습니다...