IEquatable interface for package classes about packetnet HOT 12 CLOSED

@GhostlyRaven I'm guessing we simply haven't run into the need to do so yet. Would you have any suggestion on which of the two options you proposed? What would the changes look like and require in terms of code?

from packetnet.

@chmorgan In my opinion, the more correct option is to implement the IEquatable interface for the abstract Package class in all derived package classes. In the code, you will need to implement the IEquatable interface and follow the recommendations described in documentation. In the package class code, it will look something like this:

public sealed class IPv4Packet : IPPacket, IEquatable<Packet>
{
      public static bool operator ==(Packet left, Packet right)
      {
          //Some comparison operation code
      }

      public static bool operator !=(Packet left, Packet right)
      {
          //Some comparison operation code
      }

      public override bool Equals(object packet)
      {
          //Some comparison operation code
      }

      public bool Equals(Packet packet)
      {
          //Some comparison operation code + this.PayloadPacket.Equals(packet.PayloadPacket);
      }

      public override int GetHashCode()
      {
          //Some hash operation code
      }
}

In the logic of comparing packages, I suggest using all the available fields and also running the comparison operation for the PayloadPacket field and adding it to the final result. Also I would replace the set-properties for classes of packages init-properties that have emerged in C# 9.0. This eliminates potential problems associated override GetHashCode.

P. S. To implement an interface IEquatable, you can immediately add an implementation of IComparable interface, which adds the ability to apply sorting for classes of packets placed in various collections.

from packetnet.

In the logic of comparing packages, I suggest using all the available fields

All the comparison needs is to do is compare the underlying byte segment.

from packetnet.

@PhyxionNL I'm not sure what base segment you're talking about? Do you mean the ByteArraySegment class and the fields in packages of this type? If I'm right, could you please specify where exactly what you are talking about is located in the project code? For me, this will add more clarity about your offer.

from packetnet.

ByteArraySegment indeed, for IEquatable all that's required is to do a comparison of its contained data as all fields in the packet classes use that underneath.

from packetnet.

@PhyxionNL tell me, does ByteArraySegment contain in its structure the content that we transmit over the network as a message or not? Just in my opinion, it is more correct to compare packages without the participation of content. If the content is not present in the structure or can be ignored, then you can implement all the packet comparison logic for the Packet base class by implementing the IEquatable interface and using the field containing the data as ByteArraySegment.

P.S. You can replace the byte array in ByteArraySegment with Span<byte> or ReadOnlySpan<byte> in my opinion, this will be a good change and it will allow you to quickly and easily implement packet comparison and sorting.

from packetnet.

@PhyxionNL tell me, does ByteArraySegment contain in its structure the content that we transmit over the network as a message or not? Just in my opinion, it is more correct to compare packages without the participation of content. If the content is not present in the structure or can be ignored, then you can implement all the packet comparison logic for the Packet base class by implementing the IEquatable interface and using the field containing the data as ByteArraySegment.

Yes, ByteArraySegment contains the bytes of the packet. It's not more correct to compare packets through the properties. In fact, it's less correct as not all data is always accessible through properties.

P.S. You can replace the byte array in ByteArraySegment with Span<byte> or ReadOnlySpan<byte> in my opinion, this will be a good change and it will allow you to quickly and easily implement packet comparison and sorting.

ByteArraySegment is close to a Span<byte> already, but has some useful features that Span doesn't have. A Span is stack-only, whereas ByteArraySegment can be used everywhere. It's actually more related to https://docs.microsoft.com/en-us/dotnet/api/system.arraysegment-1?view=net-5.0 (which I guess ByteArraySegment could derive from).

from packetnet.

I also spotted ArraySegment and it does look like it should be possible to swap one with the other. We do use some additional methods on BAS that would seem to require adding some extension methods, like NextSegment, but it certainly looks possible. I'm all for reusing common classes, how does it help to switch to ArraySegment beyond just reusing something that exists in .net now?

I was also interested in the applications of Span<>. We've looked at them on SharpPcap for example and its possible that we'll switch to returning spans from the lowest level code. The trouble is as @PhyxionNL says, they are stack only. So by returning a Span<> we'd force users to make a RawPacket() that copied the span. For the highest performance cases it helps, for the average user its just another mechanical step they'd have to do in their code to get an instance they can pass around, so nothing there just yet.

If we look at PacketDotNet usage it would be great if we could pass Span<> around, BUT, because its stack only you'd end up with objects that were then structs, and copy by value, which isn't ideal. Plus we do a ton of lazy evaluation in PacketDotNet.

from packetnet.

Stack-only isn't really possible for PacketDotNet as it's used throughout the project differently. You can use Memory<T> instead, but ByteArraySegment is already well optimized so I doubt it'll make a lot of difference (the same applies to ArraySegment). There's also the downside that Span/Memory is .NET Core/5+ only.

from packetnet.

@chmorgan and @PhyxionNL, thank you for explaining the device class ByteArraySegment. Now I can definitely correctly state my vision of comparing packages knowing all the missing details for me.
In my opinion, the default packets should be compared without taking into account the payload (text, file, etc.) transmitted to them over the network. However, you can make two types of comparison: partial (without taking into account the payload) and full (taking into account the payload). Partial comparison is useful when we want to intercept traffic and we are not interested in the payload of the packet, but we need to compare the packets. For example, we need to count the number of packets going to the same remote address and port, but we are not interested in what goes there. Therefore, I believe that it is possible to implement both options described above and provide the user with a choice (via the flag for example) how the packages will be compared.

P.S. I am waiting for your suggestions on this idea)

from packetnet.

With IEquatable you should compare all data (not partial, or both - which is not an option to pass in). If you have such a specific use case then you're better off implementing an extension method yourself.

from packetnet.

@PhyxionNL I just suggested a concept that is not tied to a specific implementation. If you want, you can do the following instead of implementing IEquatable, you can implement several IEqualityComparer for the options I have proposed for collections. Then the package objects will not contain the comparison logic and will just store the information. This will allow you to create different types of comparison for packages. How do you like this implementation option?

from packetnet.