PacketByte Support 라이브러리

이광석 · 3월 26, 2024, 9:17오전

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

다시 올려주세요

이광석 · 3월 26, 2024, 9:35오전

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

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

Nuget 업데이트

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

모두들 수고하셨습니다!

BOBx5 · 3월 26, 2024, 1:04오후

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

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

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

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

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

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

이광석 · 3월 26, 2024, 1:37오후

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

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

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

이광석 · 3월 26, 2024, 3:36오후

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();

메인은 Append* Type 이고 @* Type번은 확장라이브러리
메인은 @* Type 이고 Append* Type번은 확장라이브러리
1,2 정하는 건 무의미하고 둘 다 제공

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

al6uiz · 3월 27, 2024, 1:00오전

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

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

저는 1번에 한 표

dimohy · 3월 27, 2024, 1:15오전

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

제 의견은 이렇습니다.

github.com/lukewire129/BytePacketSupport

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

opened 01:00PM - 26 Mar 24 UTC

BOBx5

# 제안 새롭게 적용한 `@예약어`(e.g. `@byte(...)`) 방식을 *PascalCase* + *동사형* (e.g `App…endByte(...)`) 으로 변경 제안합니다. # 사유 ## 사용자 적응 방해 개인적으로 라이브러리의 사용자 인기 및 적용은 BCL 사용 경험과 가장 유사할수록 유리하다고 생각합니다. 그에 반해, 예약어를 메서드로 사용하는 개념이 기존 사용경험과 달라 굉장히 이질적으로 느껴집니다. ## 라이브러리 유지보수 측면 라이브러리 자체적으로 제안하는 내부 코드컨벤션으로 예약어의 메서드 사용이 제안되지 않는 상태에서, 일부분에 대해서만 예약어를 메서드로 사용하는 것이 라이브러리의 일관성을 해칠 수 있다고 생각합니다. 합리적인 이유로 내부 코드컨벤션으로 제안되고 합당하다면, 해당 내용을 문서화하여 사용자에게 전달하는 것이 더 바람직하다고 생각합니다. # 제안 사항 ## 예약어 메서드 변경 BCL에서 제안하는 *PascalCase* + *동사형* 메서드 형태로의 변경을 제안합니다. * `@short(...)` => `AppendShort(...)` * `@int(...)` => `AppendInt(...)` * `@long(...)` => `AppendLong(...)` * `@ushort(...)` => `AppendUshort(...)` * `@uint(...)` => `AppendUint(...)` * `@ulong(...)` => `AppendUlong(...)` * `@byte(...)` => `AppendByte(...)` * `@bytes(...)` => `AppendBytes(...)` * `@class(...)` => `AppendClass(...)` * `@string(...)` => `AppendString(...)` ## 예약어 메서드의 적용 예약어를 사용한 메서드 설계가 어떤 부분에 있어선 매우 직관적이고 편리할 수 있다는 점을 수용하되, 본 라이브러리가 아닌 Extension형 누겟 패키지로 별도로 생성하고 사용자 편의에 따라 추가하여 사용할 수 있도록 동일한 네임스페이스 내에서 Extensions 메서드로 사용될 수 있도록 하는게 좋을 것 같습니다. ```csharp using BytePacketSupport; using BytePacketSupport.Extensions.ReservedWords; namespace Sample; public static class Program { public static void Main() { var packet = new PacketBuilder() // BytePacketSupport .AppendShort(1) .AppendInt(2) .AppendLong(3) .AppendUshort(4) .AppendUint(5) .AppendUlong(6) .AppendByte(7) .AppendBytes(new byte[] { 8, 9, 10 }) .AppendString("Hello, World!") .AppendClass(new SampleClass()) // BytePacketSupport.Extensions.ReservedWords .Short(1) .Int(2) .Long(3) .Ushort(4) .Uint(5) .Ulong(6) .Byte(7) .Bytes(new byte[] { 8, 9, 10 }) .String("Hello, World!") .Class(new SampleClass()); // or .@short(1) .@int(2) .@long(3) .@ushort(4) .@uint(5) .@ulong(6) .@byte(7) .@bytes(new byte[] { 8, 9, 10 }) .@string("Hello, World!") .@class(new SampleClass()); } } ``` > 참조 문서 > > [일반적인 C# 코드 규칙](https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/coding-conventions) > > [.NET C# Coding Style](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md)

이광석 · 3월 27, 2024, 1:15오전

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

이광석 · 3월 27, 2024, 1:17오전

저는 3번이요…

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

@BOBx5 님의 의견

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

@dimohy 님의 의견

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

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

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

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

_mozartkkk · 3월 27, 2024, 1:47오전

추가 의견 드립니다.

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

이광석 · 3월 27, 2024, 1:53오전

안그래도 기반만 다져놓고

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

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

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

jrchs · 3월 27, 2024, 2:03오전

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

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

감사합니다.

이광석 · 3월 27, 2024, 2:08오전

감사 합니다!

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

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

Greg.Lee · 3월 27, 2024, 2:19오전

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

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

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

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

덧,

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

jrchs · 3월 27, 2024, 2:28오전

데이터가 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) 성능 차이가 얼마나 날지 궁금했습니다. 저 같은 경우 보통 수십대의 장비에 병렬로 초단위 패킷을 생성하여 통신합니다.
생각해보니 나중에 시간 되면 제가 직접 벤치마크 테스트를 해봐도 될 것 같네요.

이광석 · 3월 27, 2024, 2:30오전

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

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

이광석 · 3월 27, 2024, 2:36오전

고견 감사합니다.

참고하겠습니다!

이광석 · 3월 27, 2024, 2:43오전

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월 27, 2024, 3:14오전

음 아무리 생각해도 다 맞는 의견들인지라…
결론이 나지 않을 것 같아서 세가지 타입(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

땅땅땅?

BOBx5 · 3월 27, 2024, 3:33오전

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

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

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