sockets - C# - Could sending 5 Multicast UDP packets result in 3 or more being lost -

good day all

is possible sending multicast packet(s) on lan result in or @ least 50% of packets being lost.

my application makes use of multicast packets, when sending these packets, @ times receive 1, other times 2. 2 times received packets sent.

here tests did see packets returned/received. 5 packets sent, not returned (f - final packet in sequence of packets sent)

2000 random chars used these tests.

12345 14f

12345 134f

12345 1f

12345 1

12345 1

12345 1f

12345 134f

i recieve atleast 1 packet. understand multicast = udp, not seem normal lose many packets.

sending multicast packets:

        socket _listener_socket = new socket(addressfamily.internetwork, sockettype.dgram, protocoltype.udp);         foreach (ipaddress localip in dns.gethostaddresses(dns.gethostname()).where(i => i.addressfamily == addressfamily.internetwork))         {                             _listener_socket.setsocketoption(socketoptionlevel.ip, socketoptionname.addmembership, new multicastoption(_multiip, localip));             _listener_socket.setsocketoption(socketoptionlevel.ip, socketoptionname.multicasttimetolive, 1);             _listener_socket.setsocketoption(socketoptionlevel.socket, socketoptionname.reuseaddress, true);             _listener_socket.multicastloopback = true;             _listener_socket.connect(new ipendpoint(_multiip, _port));             int count = msgs_to_send.count;             while (count > 0)             {                                     count--;                 byte[] temp = (byte[])(msgs_to_send.dequeue());                 _listener_socket.send(temp, _byte_buffer_size, socketflags.none);                 msgs_to_send.enqueue(temp);             }         }         _listener_socket.close(); 

and recieving:

        socket _sender_socket = new socket(addressfamily.internetwork, sockettype.dgram, protocoltype.udp);         ipendpoint ipep = new ipendpoint(ipaddress.any, _port);         _sender_socket.bind(ipep);         ipaddress localip = _multiip;         _sender_socket.setsocketoption(socketoptionlevel.ip, socketoptionname.addmembership, new multicastoption(localip, ipaddress.any));         q_recieve = new queue<char[]>();         while (_sender_socket.isbound && !bstop)         {             byte[] b = new byte[_byte_buffer_size];             _sender_socket.receive(b);             char[] chars = new char[_byte_buffer_size];             system.buffer.blockcopy(b, 0, chars, 0, b.length);             q_recieve.enqueue(chars);         } 

update

some interesting results - kudo's seth suggestions

after testing firewall suggestion, received improvement still having packet loss:

i disabled kaspersky firewall, defauting windows 10 defender firewall:

12345 234f

12345 234f

12345 1234f

12345 1f

12345 14f

12345 234f

12345 1

12345 1

12345 234f

with kaspersky firewall disabled, changed byte[] size 1024 512 sending 256 char's per packet (and thread sleep time of 20ms), results improved drastically:

123456789 2345678f

123456789 2345678f

123456789 2345678f

123456789 2345678f

123456789 2345678f

only first packet being dropped, quite improvement!

yes, time sending udp there variety of factors can cause packets lost, on lan. here few seem relevant:

• 2000 bytes larger typical lan mtu of 1500 (less headers). means datagram fragmented. if fragment lost, entire datagram lost, , firewalls block fragments if arrive in patterns.
• udp has no flow control. if send data, quickly, packets dropped. sounds sending few datagrams @ time, check udp send , receive buffers. if either big enough hold 1 or 2 datagrams, rest may dropped.
• firewalls treat udp strangely. dos prevention, deep packet inspection, tunnel blocking, , bunch of security sounding buzzwords mean firewall making wild guess purpose of datagram. if firewall guesses incorrectly, of datagrams may dropped.
• it looks setting ttl 1. in theory, that's correct lan. if local routing bit off, cause packets dropped.

so, reduce payload 1400 bytes, make sure udp send , receive buffers @ least 64 kilobytes (preferably megabyte, there's no reason stingy), disable firewalls, , test larger ttl.

if of fixes problem, can dig in find exact cause.