PacketCommunicator.Break() will not help here. It's meant to stop a capture, not a transmission. As far as I see, there is no clear way to do what you wish from the Library, so I only propose workarounds. See if they help you, if not - contact the developer and ask for this feature.
Option 1 - You can send each packet separately in a loop, using PacketCommunicator.SendPacket(). This will be slower but will allow you to stop after each packet by modifying the loop's condition.
Option 2 - You can send use PacketCommunicator.Transmit but with smaller batches of packets
Change
while (inputCommunicator.ReceivePacket(out packet) == PacketCommunicatorReceiveResult.Ok)
{
sendBuffer.Enqueue(packet);
++numPackets;
}
into something like
int packetsInBatch = MAX_PACKETS_IN_BATCH;
while (inputCommunicator.ReceivePacket(out packet) == PacketCommunicatorReceiveResult.Ok && packetsInBatch > 0)
{
sendBuffer.Enqueue(packet);
++numPackets;
--packetsInBatch;
}
and put everything in another for loop. This will allow you to stop the loop after the end of the batch and is a trade-off between speed and delay after you signal to stop.
Option 3 - Mercilessly kill the send buffer. Call sendBuffer.Dispose() and handle the consequences.
[HandleProcessCorruptedStateExceptions]
private static void Transmit(PacketCommunicator outputCommunicator, PacketSendBuffer sendBuffer, bool isSync)
{
try
{
outputCommunicator.Transmit(sendBuffer, isSync);
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
You'll have to handle AccessViolationException. I have done this by adding the HandleProcessCorruptedStateExceptions attribute to a new method I created which performs the transmit (see How to handle AccessViolationException). It seems to work on my machine, but this is really a last resort solution. I wouldn't use it in anything but the simplest command line utilities without a (very) through testing. There's work with unmanaged code going on and I don't know what happens to resources when we pull this trick.