PacketByte Support 라이브러리

엇 이미 합쳐버렸지만… 뭐 다시하면되죠

다시 올려주세요 :slight_smile:

4 Likes

2.0 버전 기준으로 ReadMe 업데이트 되었습니다.
오철자 한번씩 검토부탁드리겠습니다.

(Readme 수정도 컨트리뷰터로 참여 되니 같이 수정해요 저희!)

Nuget 업데이트

집가서…2.0버전을…하핫!

모두들 수고하셨습니다!

4 Likes

개인적으로 README 에서 설명하는 변경된 사용법을 읽으면서

‘어, 다른 리포 들어왔나?’

싶을 정도로 이질감이 느껴져서 좀 당황스러웠습니다.

@byte(...) 같은 예약어를 메서드로 쓰는 부분을 다시 변경했으면 합니다.

[제안] @reservedWord 메서드의 네이밍 변경

처음으로 오픈소스에 Issue 날려봅니다 ㅎㅎ

3 Likes

감사합니다.
우선 오늘 2.0으로 올릴 계획은 잠시 멈추겠습니다!

(1.0이 심각하게 동작 안되고있어도…2.0에 완벽에 기하는게 좋을거같으니…)

p.s 저기 @BOBx5 님 작성해주신 issues로 와서 토론 참여 해주세요! 힘드시면 여기에 댓글이라도… :slight_smile:

2 Likes

Issues에 있는 내용을 더 많은 의견을 들어보고자
질문드립니다!

  • Append* Type
var pb = new PacketBuilder()
            .AppendByte(0x01)
            .AppendInt(1)
            .AppendShort(1)
            .AppendClass(new AnotherClass())
            .Build();
  • @* Type
    var pb = new PacketBuilder()
    .@Byte(0x01)
    .@Int(1)
    .@Short(1)
    .@Class(new AnotherClass())
    .Build();
var pb = new PacketBuilder()
            .@byte(0x01)
            .@int(1)
            .@short(1)
            .@class(new AnotherClass())
            .Build();
  1. 메인은 Append* Type 이고 @* Type번은 확장라이브러리
  2. 메인은 @* Type 이고 Append* Type번은 확장라이브러리
  3. 1,2 정하는 건 무의미하고 둘 다 제공

자유롭게 의견부탁드리겠습니다!

3 Likes

프레임워크 디자인 가이드에서는 프리미티브 타입의 이름은 특정 언어에 종속적인 이름(Long, Ushort)보다는 CLR의 이름(Int64, UInt16) 사용을 권장하고 있습니다.

일반 명명 규칙 - Framework Design Guidelines | Microsoft Learn

저는 1번에 한 표:blush:

4 Likes

저는 2번입니다. 다만… @Byte 보다는 @byte가 좋아요 ^^

제 의견은 이렇습니다.

2 Likes

일반 명명 규칙을보니…
AppendShort 가 아닌 AppendInt16 으로 가야할지도 모르겠단 생각이…?

2 Likes

저는 3번이요…

해당 라이브러리는…
아직까지 초기버전이라 확장라이브러리로 빼내야하는 이유이기 때문입니다.

@BOBx5 님의 의견

이 의견에 맞는 말씀이시기 때문에 필요한 것 같고

@dimohy 님의 의견

메서드 호출의 느낌 보다는 패킷을 조합하는 느낌으로 (예를 들어 에뮬레이터에서 옵코드를 동일한 개념으로 메서드로 표현하기도 합니다) 바라보면 어떨까 합니다.

메서드 호출의 느낌보단 패킷을 조합한다는 의견 때문에 필요한 것 같았습니다.


만일 1, 2번 중에 정말 고르라고 한다면 1번을 선택해서

1번의 확장라이브러리에는 PacketByteSupoort.Fusion (가칭) 과 같은 명칭을 부여해서 PacketByteSupport 메서드 호출의 느낌을 없애고 오로지 패킷의 조합을 연상케하는 컨셉의 라이브러리로 확장해가면 어떨까 하는 생각도 듭니다.

4 Likes

추가 의견 드립니다.

bit 단위 기능 적용
보통 bit 단위로도 사용할 경우도 있을 것 같은데,
byte position, bit position, bit size를 고려하여
조심스럽게 기능 추가 의견 드립니다.

5 Likes

안그래도 기반만 다져놓고

  • (@bit, AppendBit) , (@bitarray, AppendBitArray)

도 같이 넣을 계획이 있었습니다만

bit Shift 같은 의견 감사합니다!

3 Likes

좋은 라이브러리를 만들어주셔서 감사합니다. 현업에서 사용하기 매우 유용할 것 같습니다.
몇가지 추가 의견 드려도 될지 모르겠습니다.

  1. @_mozartkkk 님이 요청하신 bit 단위로 처리해야 하는 경우가 현업에서 정말 많습니다. 저도 이 기능 추가 요청드립니다.
  2. byte swap 기능을 사용하는 장비들도 많이 있습니다. byte swap 기능도 추가되면 좋을 것 같습니다.
  3. 혹시 가능하면 벤치마크 테스트가 가능할까요? 보통은 Packet을 만들 때 byte 배열을 생성하고 여기에 데이터를 copy 하게 되는데요. 이것과 비교해서 성능 차이가 얼마나 날지 궁금하네요.

감사합니다.

3 Likes

감사 합니다!

역순기능을 말씀하시는건가요? 특정 Byte배열의 역순을 말씀하시는건지요…!

비교군에 대한 대상을 좀 받아볼수있을까요!

2 Likes

컨벤션관련 의견을 드리자묜…

패킷을 조합한다는 의미도 좋지만
그것을 메서드를 통해 구현한다. 가 C# 개발자의 상식에 가깝지 않나 싶습니다.

혹, 만약 이 구현체를 인터페이스로 제공한다고 했을 때에도
기존 프로젝트에서 컨벤션 충돌 없이 사용하려면 @type() 보다는 기존 메서드 컨벤션을 따르는 것이 유리해 보여요.

다만 나름 의미나 선호도 있을 수 있으니
@type() 요 방식은 extension 으로 제공되면 알잘딱 사용할 수 있을 거 같기도 해요.




덧,

@type() 요 방식은 IDE 에서 밑줄 쎄게 얻어맞을 가능성이 높아요…
(올 그린 강박이 있는 저에겐 무리…=ㅅ=;;; )

5 Likes

image
데이터가 byte 배열에 이렇게 저장됩니다.

		var packetNew = pb
		  .@byte(0x01)  // CMD
		  .BeginSection("ChecksumPacking")
		  .@byte(0x02)
		  .@byte(0x03)
		  .@byte(0x04)
		  .@byte(0x05)
		  .EndSection("ChecksumPacking");
		  .Compute("ChecksumPacking", Checksum8Type.Xor)
		  .Build();		
  
		byte[] packetOld = new byte[5];
		packetOld[0] = 0x01;
		var data = MakeData();
		Array.Copy(data, 0, packetOld, 1, 4);
		var crc = ComputeCRC(data);
		Array.Copy(crc, 0, packetOld, 5, 2);

보통은 패킷을 생성할 때 packetOld와 같이 생성했었는데, PacketBuilder로 똑같이 생성했을 때(packetNew) 성능 차이가 얼마나 날지 궁금했습니다. 저 같은 경우 보통 수십대의 장비에 병렬로 초단위 패킷을 생성하여 통신합니다.
생각해보니 나중에 시간 되면 제가 직접 벤치마크 테스트를 해봐도 될 것 같네요.

5 Likes

Enidan개념에 Swap있었군요…참고하여 적용해볼게요!

현재1.0 버전보단 2.0을 기다려주세요!
1.0에 버그가 있는데 고치지않고 넘어가는거라…!

3 Likes

고견 감사합니다.

참고하겠습니다!

3 Likes

Array.Copy보단 Buffer.BlockCopy로 이용하고 있기 때문에 기존에 만드셨던 로직의 성능과는 큰 이슈가 없을거라고 봅니다. ( Array.Copy보단 Buffer.BlockCopy가 더 좋다는 얘기가 있긴합니다만…정확하게 뭐가 맞다는 저도 좀 봐야할거같아서…)

다른 성능 테스트 건에 대해 진행한 것이 있긴합니다.

private byte[] TestData()
{
    byte[] arrByte = {0x01};
    for(int i=0; i<10000; i++)
    {
       arrByte.Append<Byte>(BitConverter.GetBytes(i));
    }

    return arrByte;
}

테스트 1

byte[] sourceByte = new byte[]{0x05,0x05,0x05,0x05};
byte[] testData = TestData();
for(int i=0; i<testData.Count(); i++)
{
   arrByte.Append<Byte>(testData[i]);
}

테스트 2

byte[] sourceByte = new byte[]{0x05,0x05,0x05,0x05};
byte[] testData = TestData();

arrByte .@bytes(testData);

한번에 밀어 넣는방식과 bytes array(Buffer.BlockCopy) 이 두개의 테스트군을 진행했었는데
이때, testData 데이터 크기가 적을 땐 하나씩 밀어넣는 방식이 좀 더 빨랐고
반대로 크기가 클 수록 BlockCopy방식이 빨랐습니다.

3 Likes

음 아무리 생각해도 다 맞는 의견들인지라…
결론이 나지 않을 것 같아서 세가지 타입(CLR, csharp, dimohy님 제안)모두 지원하고자 합니다.
(향후 분리를 한다해도 나누면 그만이니…)

  • AppendByte = @byte
  • AppendBytes = @bytes
  • AppendString = @string
  • AppendInt32 = Appendint = @int
  • AppendInt64 = Appendlong = @long
  • AppendInt16 = Appendshort = @short
  • AppendUInt32 = Appenduint =@uint
  • AppendUInt64 = Appendulong = @ulong
  • AppendUInt16 = Appendushort = @ushort
  • AppendClass = @class

땅땅땅?

2 Likes

Git Discussion
@예약어 메서드의 네이밍 변경의 건

논의된 내용을 바탕으로 후보 추려서 투표 올렸습니다!

많은 투표 부탁드립니다~~~

4 Likes