PDA

View Full Version : UDP Broadcasting into complete LAN? Are you shure to want this?



Snoopy
15-12-2015, 14:16
Hi,

UDP Streaming was realizied in pCARS in order to give a second possibility like the "Shared Memory" to collect Data out of pCARS.
Good intention, nice attempt, but...

I don't know why those UDP Output broadcasts are going into the complete Network?

I call something like that Broadcast-Flooding, others maybe call it DoS.
If someone sets his UDP Sending into fastest Mode, some Devices in the Network will fail, because of Traffic-Flooding.

Noone can tell Users to create VLANs in his LAN in order to keep the Network Traffic down or calm.
This cannot be the solution SMS...

Force the users to set IP Adresses in pCARS, which devices should receive Data (and only those!).
Make the UDP Stream configure-able to 3-5 Devices and everything is good.
The traffic should only go to those Devices (configured by IP), not more or less.

Don't yell everything into the complete Network, like a LAN-UDP-Broadcast-Monster...
Nothing else is pCARS if someone enables this Option...

Snoopy
17-12-2015, 09:04
*push

Vittorio Rapa
17-12-2015, 23:27
The traffic impact on the network is negligible even at the fastest rate, there won't be any device flooded by the UDP packets because those devices won't reply with a ICMP on the 5606 port (that is a prerogative to have a such flood having any effect at all): you're applying the theory of a UDP attack to the wrong scenario.
Is it yours just a theory based on a wrong assumption, or do you really had issues because of it? If so, I'm curious to see the bad effects you may have noticed and we can discuss about it.

graveltrap
18-12-2015, 11:03
I experienced both my phone and laptop being unable to connect to my Wireless network when I had the UDP set to 1, in game, I am also experiencing some lag when playing online since I started using the feature (currently at 5).

I will turn it down to 7 (as advised by another forum user) and try again to see if it improves matters...

I am on a Virgin media connection in the UK, using the router they provide (no idea if that information is of use).

Vittorio Rapa
18-12-2015, 12:49
I'm not sure how the UDP traffic could affect the capability of a device to connect via WiFi (if anything it could affect the traffic, not the connection to the router), and even if it affects the router (ie: the router software can't handle the stream), those devices aren't connected to the network at all, so the cause couldn't be them being "flooded" by some UDP traffic.
On the other side, it will certainly affect the same PC where PCARS is running (it would be the same if you stream the traffic to a single IP), that's indeed normal and it depends by your specs, if your PC (our your router) can't handle the load, I recommend to lower the update frequency.

graveltrap
18-12-2015, 13:07
I have no idea how this stuff works, I can only report what I have seen.

My PS4 that is running the game is hard wired to the router, so I guess the problem is with that device.

Vittorio Rapa
18-12-2015, 13:49
My PS4 that is running the game is hard wired to the router, so I guess the problem is with that device.

Probably the router cannot handle the speed of the data sent by the PS4, but that's another issue (related to router), it's not because of a traffic sent on the broadcast address rather than a specific IP, in other words it's not related to this thread (or the concerns of the OP).

ermo
18-12-2015, 14:01
I'm not sure how the UDP traffic could affect the capability of a device to connect via WiFi (if anything it could affect the traffic, not the connection to the router), and even if it affects the router (ie: the router software can't handle the stream), those devices aren't connected to the network at all, so the cause couldn't be them being "flooded" by some UDP traffic.
On the other side, it will certainly affect the same PC where PCARS is running (it would be the same if you stream the traffic to a single IP), that's indeed normal and it depends by your specs, if your PC (our your router) can't handle the load, I recommend to lower the update frequency.

Can we agree that e.g. WiFi is Carrier Detect Multiple Access with Collision Detection (CDMA/CD), right? So in theory, it is possible for the PS4 to hog the carrier media if you broadcast continuously onto a WiFi network, such that other WiFi devices connected to the AP will trigger the exponential backoff algorithm in their network stacks when they try to connect and find the media occupied by the UDP packets?

It wouldn't surprise me to hear that this was an issue to people who have no clue how a WiFi network works on a technical level (and why it is essentially the worst possible form of networking equipment -- hello BNC 10base2 thin ethernet). It's completely different if you have a wired and switched network, of course!

Vittorio Rapa
18-12-2015, 14:56
I'm not sure how the UDP traffic could affect the capability of a device to connect via WiFi (if anything it could affect the traffic, not the connection to the router), and even if it affects the router (ie: the router software can't handle the stream), those devices aren't connected to the network at all, so the cause couldn't be them being "flooded" by some UDP traffic.
On the other side, it will certainly affect the same PC where PCARS is running (it would be the same if you stream the traffic to a single IP), that's indeed normal and it depends by your specs, if your PC (our your router) can't handle the load, I recommend to lower the update frequency.

Can we agree that e.g. WiFi is Carrier Detect Multiple Access with Collision Detection (CDMA/CD), right? So in theory, it is possible for the PS4 to hog the carrier media if you broadcast continuously onto a WiFi network, such that other WiFi devices connected to the AP will trigger the exponential backoff algorithm in their network stacks when they try to connect and find the media occupied by the UDP packets?

It wouldn't surprise me to hear that this was an issue to people who have no clue how a WiFi network works on a technical level (and why it is essentially the worst possible form of networking equipment -- hello BNC 10base2 thin ethernet). It's completely different if you have a wired and switched network, of course!

It's more likely that the network traffic is hogging that router CPU (it's not uncommon, whenever it normally happens when there's some heavy traffic involved, like p2p applications and such), since he specified that his PS4 is wire connected to the router, the WiFi is not directly affected by the traffic.

MikeyTT
18-12-2015, 15:13
So I'm no networking expert by any means, but what you're (OP) suggesting is to go from broadcast to unicast?, i.e. from sending to all devices in the network, to just a list of devices.

This will potentially increase the traffic on the network. For each slice of telemetry data a broadcast, or multicast for that matter, will send only once for as many clients as you like to consume that on. By targeting specific devices, you are sending that slice of telemetry data to each one. No overhead if you have 1 device, but for every one you add, that's doubling/tripling the traffic on the wire. If you're lucky enough to have a switch segmenting the traffic that's not too bad, other than it's more traffic from the console. But if you're sat on a single wireless segment, as I imagine a lot of peeps will be, then it will just compound the problem.

Not to mention trying to explain to a lot of non-technical people how to get their devices IP address, put it in the pCars UI, and what happens if the DHCP address changes, etc. That would be a bad solution IMO.

ermo
18-12-2015, 16:22
It's more likely that the network traffic is hogging that router CPU (it's not uncommon, whenever it normally happens when there's some heavy traffic involved, like p2p applications and such), since he specified that his PS4 is wire connected to the router, the WiFi is not directly affected by the traffic.

If the PS4 is broadcasting to the entire network broadcast domain, network logic dictates that it is also broadcasting packets over the WiFi network radio, which employs CDMA/CD. I'm not discounting your suggestion and your experience here, just pointing out that WiFi *could* be problematic as well.

But I guess he'd need to install network monitoring software on both the router and the WiFi devices to find the root cause of the perceived slowdown. :)

Vittorio Rapa
18-12-2015, 17:52
It won't broadcast anything over WiFi, if there's no device connected (yet), since no route is created.
Anyway whatever it is the cause, it has nothing to do with broadcast, and more in general as Mikey have pointed: having an asynchronous traffic toward different destinations would increase the traffic if anything.
I'll wait for the OP reply then I'll close it.

JoeZarkos
18-12-2015, 22:40
I experienced both my phone and laptop being unable to connect to my Wireless network when I had the UDP set to 1, in game, I am also experiencing some lag when playing online since I started using the feature (currently at 5).

I will turn it down to 7 (as advised by another forum user) and try again to see if it improves matters...

I am on a Virgin media connection in the UK, using the router they provide (no idea if that information is of use).

The SuperHubs on Virgin are notoriously horrific in general, let alone gaming (I have one unfortunately, so I can understand how frustrating it is). Just have a Google and you'll see the endless VM forum threads.

However, I've experienced no UDP issues (UDP 1) with the SuperHub2.

ermo
19-12-2015, 11:54
It won't broadcast anything over WiFi, if there's no device connected (yet), since no route is created.
Anyway whatever it is the cause, it has nothing to do with broadcast, and more in general as Mikey have pointed: having an asynchronous traffic toward different destinations would increase the traffic if anything.
I'll wait for the OP reply then I'll close it.

I never suggested that several unicast connections would be a better alternative, just so that's clear. Besides, on WiFi this would make no difference anyway IF the issues are due to the exponential backoff of CDMA/CD (and I'm only suggesting this as a possibility, not a fact).

And for the record, I'm talking about graveltrap's observations where his phone and laptop were connected via WiFi, so I'm not sure I understand why you're mentioning the part about no device being connected? :)

When I get home I'll be sure to do some tcpdump tests of my own on my OpenWRT WiFi router and share my findings here.

Vittorio Rapa
19-12-2015, 12:13
I never suggested that several unicast connections would be a better alternative

That was about the OP thoughts/request (that is the reason of why he created this thread), not yours. ;)

Also, Gravel said that his devices were unable to connect to the WiFi, hence the problem exists before any traffic (over WiFi) is created at all, that's why I said the problem is probably due to a "poor" router.

graveltrap
19-12-2015, 12:56
I checked again, with UDP at 3 my devices get disconnected from the network when a session starts and then don't seem to be able to reconnect until I slow it down. The PS4 does not get disconnected, being wired an all.

Whilst I do believe it is my crappy router that can't cope with the speed, UDP is the route cause of the problem, I would never have even know about it if the update had not happened! Everything works at 5 but I see lag in online races. I will slow it down to 7 and see if it gets rid of the lag.

It's a great feature, and very welcome it's just some guidance is needed for those that don't understand these things ;)

Vittorio Rapa
19-12-2015, 14:28
Everything works at 5 but I see lag in online races.

It shows that isn't just a WiFi issue, but the router software can't cope with the traffic, probably the device gets disconnected and won't reconnect because the router can't even handle the WiFi connections (prior that the UDP/TCP traffic). I would recommend to use a different router at this point.

graveltrap
19-12-2015, 15:45
Agreed, I have started looking at options but it is probably a cost too much, I will try and get the latest version out of the provider ;) Or just use the data offline :(

Mascot
19-12-2015, 15:53
Agreed, I have started looking at options but it is probably a cost too much, I will try and get the latest version out of the provider ;) Or just use the data offline :(

Cheap-as-chips routers in abundance on eBay if you know the specs/model of one that'll work, Grav. People can't give them away.

Tim Mann
19-12-2015, 18:26
And just to close the thread.....

One of the 1st parties specified exactly how the data had to be output (local broadcast, one-way traffic only), so our hands were pretty tied there. Oddly the only thing they didn't specify was the port number, they just gave me an absolutely massive list of ports to avoid...

bradleyland
19-12-2015, 23:17
It's remarkable that this small amount of data is clogging up people's networks. I just scripted up a capture utility because I was curious what was coming over the wire. We're not talking about a lot of data.

UDP 9 01/sec (1000ms)
Sample 1: Collected 31744 bytes in 15 (rate 2116 bytes/s).
Sample 2: Collected 30720 bytes in 15 (rate 2048 bytes/s).
Sample 3: Collected 31744 bytes in 15 (rate 2116 bytes/s).
Sample 4: Collected 30720 bytes in 15 (rate 2048 bytes/s).
Sample 5: Collected 30720 bytes in 15 (rate 2048 bytes/s).

UDP 1 60/sec (16ms)
Sample 1: Collected 1846272 bytes in 15 (rate 123084 bytes/s).
Sample 2: Collected 1840128 bytes in 15 (rate 122675 bytes/s).
Sample 3: Collected 1844224 bytes in 15 (rate 122948 bytes/s).
Sample 4: Collected 1842176 bytes in 15 (rate 122811 bytes/s).
Sample 5: Collected 1844224 bytes in 15 (rate 122948 bytes/s).

With UDP 9 in place, transmission rates are expectedly very low. With the most aggressive settings, you're looking at 120 KB/s, or 960 kbps in network parlance. That's still less than 1 mbps, which should be no problem at all for a wireless network.

I can't argue with empirical evidence, but it does seem odd that anyone would have much trouble with the small amount of broadcast traffic going on here.

Here's the script in case anyone else would like to try. You'll need a Ruby interpreter.


#!/usr/bin/env ruby

require 'socket'

DURATION = 15 # Length of time to capture in seconds
ITERATIONS = 5 # Number of times to perform the capture

BasicSocket.do_not_reverse_lookup = true

client = UDPSocket.new
client.bind('0.0.0.0', 5606)

begin
ITERATIONS.times do |i|
buffer = "".force_encoding("ASCII-8BIT")
target = Time.now + DURATION
while Time.now < target
data, addr = client.recvfrom(1024)
buffer << data
end
puts "Sample #{i+1}: Collected #{buffer.bytesize} bytes in #{DURATION} (rate #{buffer.bytesize/DURATION} bytes/s)."
end
rescue Interrupt
puts "Exiting..."
end

client.close

RamjetX
13-01-2016, 02:43
UDP Broadcast itself possibly isn't as bad as it seems. But there can be problems with UDP Broadcast messages when your networks have Networked PC's in sleep/low power/Wake on Lan enabled.

These PC's being in a low power state react to UDP broadcast messages for monitoring the magic packet to wake up the PC. The problem is that because the NIC's are in a low power state, they open and inspect the packets and an incredibly slow speed. And whilst they are doing this, the network isn't completely free to continue until the packet is rejected by the NIC.

I have experienced this with a HDMI Network broadcaster which uses UDP Broadcast messaging to send the video data across the network. This is a Gigabit network with quality of service enabled etc. And a single PC on the LAN in sleep mode with Wake On Lan enabled would cause packet latency so sever that the visual effect was stuttered and erratic video transmission.

If I turned that PC ON. And the device had booted. There was Zero latency in the network. I spent hours fault finding, new switches, cabling, bridging out switches, direct cabling etc.. and without a doubt. This was the problem!

If anyone is experiencing latency/drop outs/timeouts etc with UDP Broadcast messaging. Check if any other device on the network is in a low power state and turn it on to monitor if speeds appear to pick up.

RamjetX

UDP Broadcasts are fine... so long as the slowest device on the network isn't asleep, in a low power state with WOL enabled.

bradleyland
13-01-2016, 04:23
UDP Broadcast itself possibly isn't as bad as it seems. But there can be problems with UDP Broadcast messages when your networks have Networked PC's in sleep/low power/Wake on Lan enabled.

These PC's being in a low power state react to UDP broadcast messages for monitoring the magic packet to wake up the PC. The problem is that because the NIC's are in a low power state, they open and inspect the packets and an incredibly slow speed. And whilst they are doing this, the network isn't completely free to continue until the packet is rejected by the NIC.

I have experienced this with a HDMI Network broadcaster which uses UDP Broadcast messaging to send the video data across the network. This is a Gigabit network with quality of service enabled etc. And a single PC on the LAN in sleep mode with Wake On Lan enabled would cause packet latency so sever that the visual effect was stuttered and erratic video transmission.

If I turned that PC ON. And the device had booted. There was Zero latency in the network. I spent hours fault finding, new switches, cabling, bridging out switches, direct cabling etc.. and without a doubt. This was the problem!

If anyone is experiencing latency/drop outs/timeouts etc with UDP Broadcast messaging. Check if any other device on the network is in a low power state and turn it on to monitor if speeds appear to pick up.

RamjetX

UDP Broadcasts are fine... so long as the slowest device on the network isn't asleep, in a low power state with WOL enabled.

No offense, but there is so much wrong here, you should probably remove this. You couldn't have been dealing with UDP only if a slow client caused an issue on a switched Ethernet network. UDP is fire-and-forget. The network does not wait for slow clients with UDP. If UDP packets don't reach their destination, or if the client fails to receive them, there is no consequence. The packets keep flowing.

The only context in which a slow client can cause issues is WiFi, where a wireless AP may throttle the UDP broadcast (depending upon implementation) for a slow client, because WiFi is shared media. Switched ethernet is not.

Vittorio Rapa
13-01-2016, 09:36
I'm closing this thread to not cause any confusion, the conclusion is: there's no problem with PCARS and the UDP broadcasting packets.