I have to make a program to receive information from a CPU card (serial, name, Ip etc....) the dialogue must be in UDP with Broadcast the address of the card is 2.205.52.75 and the subnet 2.255.255.255 I think, I start in network. does anyone have a sample code to get started.
Best regards,
Sébastien
Related
I am trying to let two or more ESP32-S2s communicate from one to the others over udp. Since they possibly dont know each others ip i wanted to use multicast.
Sending MulticastPackets is working.(At least I can wireshark the Packets on my PC).
Recieving on the other esp doesnt work so far.
Im Broadcasting to 192.168.178.255:7777
The reciever uses the following code:
//Called once after Wifi is connected:
udp.beginMulticast(OAL_Broadcast, OALPort); // 192.168.178.255, 7777 as inputs
//Called periodically :
Serial.println(udp.parsePacket()); // In my case always returns 0
What am I missing?
A few things could be happening.
The multicast IP address range is between 224.0.0.0-239.255.255.255 and usually a device joins a multicast group on one of those. Also it might treat sending a multicast more loosely when it comes to the IP address but receiving one it must be within the range of multicast addresses due to how it routes that packet to a multicast group.
If one device is on another network device but still on the same network then it could be ttl related and each network device is treated as a hop. I have seen something like this happen before. You might be able to adjust that on the network device side or on the esp32 side.
As a new DPDK user, I am grateful if someone can help answer following basic questions.
I see from the document and source code, there are packet type (e.g.,
172 IPV4 GTPU IPV4 TCP PAY4), packet classification type (pctype),
and flow type (e.g., 0 to 22). What are these types and their
relations?
DPDK has to map hardware type (pctype?) to the software
flow type to run RSS. Why is this and how it is done?
DPDK has mempool and it can allocate interleaved memory based on channels and ranks. But I don't understand how it is done (e.g., in the two figures in the link).
Last question is about the pktgen. Can it send e.g., 10 packets and stop? Or can it send pcap file once after it's loaded? I found it just keeps sending packets over and over.
Thanks.
Can it send e.g., 10 packets and stop?
Yes
set 0 count 10
While 0 is the port number
We've used pktgen-dpdk to send 1000000 packets and the remote could receive such number of packets.
When a host sends out a broadcast, how does it calculate the number of packets (same) that it needs to send out so that all the other hosts on the same LAN would receive it? For example, when a host boots up, it sends a DHCP broadcast to all the other hosts in the LAN. How can it determine the number of packets (same) to send?
Ok, double checked with wikipedia. You mention both "broadcast/multicast" in your title, but they're significantly different from each other.
There is no calculation for broadcast. The answer is, you don't know, or care, how many other hosts are out there. You send a single packet to the broadcast address, and it's the responsibility of every host listening to act on the packet that was sent. On a Class C subnet, such as a 192.168.x.x, the broadcast address is 192.168.x.255.
With multicast, the originating host still only needs to send out one packet, so again, no calculation of total packets is needed. From wikipedia:
Multicast uses network infrastructure efficiently by requiring the
source to send a packet only once, even if it needs to be delivered to
a large number of receivers. The nodes in the network take care of
replicating the packet to reach multiple receivers only when
necessary.
I want to search for my media player on the network. Am I right in thinking it is done using SSDP m-search?
Also, when I switch the device on, will it broadcast its availability? How do I go about listening for that broadcast, and how do I send the m-search query?
I want to search for my media player on the network. Am I right in thinking it is done using SSDP m-search?
Yes.
Also, when I switch the device on, will it broadcast its availability?
Yes
How do I go about listening for that broadcast, and how do I send the m-search query?
You need to bind to the UDP multicast group 239.255.255.250:1900. The M-SEARCH query is sent to the same address.
Both.
In general, a UPnP device will advertise itself from time to time via a NOTIFY message.
At the same time, other devices can broadcast an M-SEARCH message to ask local devices on the network if they meet it's query, and if so, will/should cause those devices to re-advertise themselves again.
So yes... you could do a search for your media player via an M-SEARCH message, looking for a urn:schemas-upnp-org:device:MediaRenderer:1
As for how you send an M-SEARCH query... UDP multicast is the protocol SSDP uses, so sending a broadcast message via that depends on the language & libraries you are using.
I'm attempting to send multichannel audio over WiFi from one server to multiple client computers using UDP broadcast on a private network.
I'm using software called Pure Data, with a UDP broadcast tool called netsend~ and netreceive~. The code is here:
http://www.remu.fr/sound-delta/netsend~/
To cut a long story short, I'm able to achieve sending 9 channels to one client computer in a point-to-point network, but when I try to do broadcast to 2 clients (haven't yet tried more), I get no sound. I can compress the audio and send 4 channels compressed (about 10% size of uncompressed) over UDP broadcast to 2 clients successfully. Or I can send 1 channel over UDP broadcast to 2 clients, with some glitches.
The WiFi router is a Linksys WRT300N. All computers are running Windows XP. The IP addresses are 192.168.1.x, with subnet mask 255.255.255.0 and the subnet broadcast address: 192.168.1.255.
I'm curious - what happens to UDP broadcast packets in the router?
If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
My WiFi bandwidth is at least 100Mbps, but I can't seem to send audio of more than around 10Mbps over UDP broadcast to multiple clients.
What's stopping me from sending audio up to the bandwidth limit of the WiFi?
any suggestions for socket code modifications, network setups, router setups, subnet modifications... all very much appreciated!
thanks
Nick
Your problem is caused by the access point's rate control algorithm. With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
The simplest solution is to not use multicast when you have a small number of WiFi receivers.
Are all parties connected via WiFi or is the sender using a
wired connection to the Access Point? Broadcast data will
be transmitted as unicast data from a station to an access
point and the access point will then retransmit the data
as broadcast/multicast traffic so it will use twice the
on-air bandwidth compared to when the sender sits on the
wired side of the AP.
When sending a unicast frame the AP will wait for an ACK
from the receiving station and it will retransmit the
frame until the ACK arrives (or it times out). Broadcast/multicast
frames are not ACKed and therefore not retransmitted.
If you have a busy/noisy radio environment this will
cause the likelyhood of dropped packets to increase,
potentially a lot, for multicast traffic compared to unicast
traffic. In an audio application this could certainly be audible.
Also, IIRC, broadcast/multicast traffic does not use the
RTS/CTS procedure for reserving the media which exarbates
the dropped packets problem.
It could actually be the case that multiple unicast streams
work better than a single multicast stream under less-than-ideal
radio conditions given that the aggregated bandwidth is
high enough.
If you can I would suggest that you use wireshark to sniff
the WiFi traffic and take a look at the destination address
in the 802.11 header. Then you can verify if the packets
are actually broadcast or not over the air.
Your design is failing due to a common misconception with WiFi speeds. With 802.11n the number 300mb/s is the link speed, not the actual bandwidth available for user data or even the IP layer. The effective bandwidth is closer to 40mb/s best case, have a look at the FAQ on SmallNetBuilder.com that discusses this in further detail.
http://www.smallnetbuilder.com/wireless/wireless-basics/31083-smallnetbuilders-wireless-faq-the-essentials
I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
No the "router" doesn't make 254 individual packets. Furthermore, I suspect the protocol leverages "multicast" addresses rather than using a "broadcast" address.
Since broadcast/multicast traffic can easily be misused, there are many networking equipment that limit/block by default such traffic. Of course, some essential protocols (e.g. ARP, DHCP) rely on broadcast/multicast addresses to function and won't be blocked by default.
Hence, it might be a good thing to check for multicast/broadcast control knobs on your router.