Some of the servers I join I’ve also noticed that it feels like my character is running through knee deep water.
could be a server issue. I haven’t come across any issue other than delayed kill messages.
Rev0verDrive wrote: »
TCP isn’t used because the packets are time sensitive.
The problem with TCP is that it abstracts data delivery as a reliable ordered stream. Because of this, if a packet is lost, TCP has to stop and wait for that packet to be resent. This interrupts the steady stream of packets because more recent packets must wait in a queue until the resent packet arrives, so packets are received in the same order they were sent. This adds to delay (LAG).
Hence one of if not the main reasoning behind using UDP. For reliability a custom system is layered on top of UDP. The goal of a reliability system is to know which packets arrive at the other side of the connection. This is done by sequencing, yet unlike TCP it does not resend packets with a given sequence number. This helps avoid out of order receival.
The game never stops and resends packet n if it was lost. Resends are left up to the application to compose a new packet containing the data that was lost, if necessary, and this packet gets sent with a new sequence number. Determining resend is based on non receival of an ack.
Determining loss
Because of the inherent holes in the reliability system, multiple acks must be included in each packet. Couple this with redundancy sends to ensure that both the client and the server receive acknowledgements for received packets.
An ack is an acknowledgement of receival. Consider it a receipt for a packet’s arrival and acceptance.
Using an ack bitfield (4 bytes per ack) you send multiple acks per packet, multiple times, just in case one packet with the ack doesn’t get through. For a 60 tick server you would send 63 acks per packet.
For clarity…
The server just received packet “1000” from the client. It in turn creates an ack for packet 1000. This ack will be the first ack in the ack bitfield, followed by the 62 previous acks. On the next receival it will generate an ack for the new packet, that ack will be the first ack in the bitfield, followed by the ack for packet 1000 and the previous 61 acks.
This ensures that the client/server will receive the acknowledgement. If you don’t get an ack for a packet within 1 second of projected arrival time, then it is considered as lost.
- Each time a packet is sent, we increase the local sequence number
- When a packet is received, the sequence number of the packet is checked against the remote sequence number. If the packet sequence is more recent, update the remote sequence number.
- When the packet headers are composed, the local sequence becomes the sequence number of the packet, and the remote sequence becomes the ack. The ack bitfield is calculated by looking into a queue of up to 63 packets, containing sequence numbers in the range [remote sequence - 62, remote sequence]. Set bit n (in [1,62]) in ack bits to 1 if the sequence number remote sequence - n is in the received queue.
- Additionally, when a packet is received, ack bitfield is scanned and if bit n is set, then we acknowledge sequence number packet sequence - n, if it has not been acked already.
sounds like fifas issue.
I’m sorry but that just doesn’t make any sense. You’re talking about reliability in receival of time-sensitive data.
If any conspiracy road is to be travelled it would be one in which DICE would be bloating loss vs concealing it. High loss stipulates the problem is outside their control and not a product design issue. Low loss and there’s still an issue points directly at the product.
I see no conspiracy, nor bloat/concealment of data.
I see a focus on accessibility which is a market wide trend.
Buffer scaling is a different topic all together. From what I remember from Mischkag’s posts he did include a clamped time limit on late data. Specifically pertaining to shots fired. This beyond the limit of the ping threshold.
Game seems to be playing well for me but I play Dom. Maybe small modes have less issue? In any event … Still the best BF ever imo.
I was being general, nothing specific. (I don’t know enough about packet handling to do that).
i think theory is more apt.
if you break down the protocols it makes no sense to delay or kick tcp…because it will resend.
with icmp this will show up if you “hinder it”…they have other ways around this though by simply avoiding measuring it on hops en route…hence the blank nodes.(on a side not most of these show up with udp ping and the majority show issues)…i dont buy isp’s explanations because when im playign and i see issues i also have problems with games…when there are no issues games pay well…
back to icmp…if people can see problems they will complain…so why hinder it.
that leaves good old udp.
if a network is getting close to it level where it has to do something what do they do…just leave it and hope it doesnt happen?
no they re route…but are they re routing all traffic?
no imo
im seeing differences in graphs between icmp and udp on certain parts of routes.
the net result is a differnt latency for icmp compared to udp.
this isnt conspiracy.
You seem to be somewhat versed in TCP, but I recommend a refresher.
TCP vs UDP
TCP is a connection oriented stream over an IP network. It guarantees that all sent packets will reach the destination in the correct order. This implies the use of acknowledgement packets (ACKS) sent back to the sender, and automatic retransmission, causing additional delays and a general less efficient transmission than UDP.
UDP is a connection-less protocol. Communication is datagram oriented. The integrity is guaranteed only on the single datagram. Datagrams reach destination and can arrive out of order or don’t arrive at all. It is more efficient than TCP because it uses non ACK. It’s generally used for real time communication, where a little percentage of packet loss rate is preferable to the overhead of a TCP connection.
TCP requires a 3 packet exchange with ACK’s to establish a connection before any application data is sent. When a packet is lost, the connection bottlenecks until the lost packet resend is received and acknowledged. This adds tremendous amounts of lag. During the retransmission of the lost packet, no other packets are sent. Any actions you take during the retransmission are backlogged for later transmission. The backlog is buffered based and can be only so large.
If the packet loss spike is severe the connection will be severed. Resulting in a reconnection process of a 3 packet exchange with acknowledgements. AGAIN more LAG. If the packet loss exceeds a specific amount (system dependent) client server desync will happen. This will result in a complete disconnection from the game.
Thus the reasoning for using UDP over TCP. With UDP security and reliability are added in at the Application layer.
TCP protocol use: HTTP, HTTPs, FTP, SMTP, Telnet
UDP protocol use: DNS, DHCP, TFTP, SNMP, RIP, VOIP
References:
https://en.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols
https://en.wikipedia.org/wiki/User_Datagram_Protocol
https://www.howtogeek.com/190014/htg-explains-what-is-the-difference-between-tcp-and-udp/
Network Rerouting
When a network is overloaded it will reroute a percentage of the traffic to alleviate the extra load. It is only this “extra” load that is clogging the route. Therefore for efficiency sake you only reroute the excess. Rerouting the entire load takes more time and resources then mitigating the excess.
Ping vs Latency
ICMP(type 8) does not process data. It is strictly used for PING. It is a very small request/response handshake. ZERO DATA is sent, nor processed.
ICMP requests are routed to a specific box at the datacenter in which the game server resides. All pings (ICMP) for all clients regardless the application are done this way…at every datacenter.
For clarity “Any request” using the ICMP protocol upon reaching the datacenter are routed to a Pingsite server. The Pingsite handles ALL ICMP requests irregardless if it’s for a game server, web server, database etc. This is done to reduce the connection load and resource usage of the application server. Once data reaches the datacenter it’s mere MICROseconds from DNS to Box.
The TERM latency is generally synonymous with ping. But that is not the case when it comes to games.
Latency (UDP) is not equal to PING (ICMP). It is the round trip of a datagram + server side processing time. client data is processed. Latency is affected by server load.
So of course there are going to be differences when comparing 2 separate strings. Ping is ICMP, Latency is UDP (round trip and processing of a datagram).
Your insults prove you’re not here to help so don’t project. What you’re claiming isn’t mutually exclusive. You do know that right? Also I’m not hating anyone, I’m point out DICE’s failures. If you comprehended what you read, you would know that.
I’m talking about him claiming something that happens every day never happens. Go back and read his posts. Your comprehension needs work.
What has he claimed doesn’t happen, yet you see every day?
Maybe an explanation cross up.
What did I state that is not mutually exclusive?
Being ignorant isn’t preferable, but to acknowledge ignorance is not necessarily an insult. I didn’t mean to insult you, but you blaming the designer is not beneficial (there is a netcode team, and they answer to production leads, who answer to EA). Just trying to shed some light, as knowledge is power.
You claim the dev that interacted here doesn’t understand, that’s not true.
DICE recognizes that a large portion of the audience has poor connections, due to the backlash of the initial 100ms cap, there isn’t much chance of DICE clamping down on poor connections again. This is unfortunate as there are tangible issues regarding player desync still in the live client, that doesn’t mean things are being ignored.
You blame all of the netcode problems of the last three games on one dev, I’d love to see the factual evidence you have to back up that opinion, from my perspective, it seems like a purely negative assumption.
Fast Questions:
- Is there still a cap?
- What is the ms level?
- What happens when a player(s) exceed this cap?
Thank you,
Yes, there is a ping threshold cap.
US and Europe: 160ms
All other Regions: 200ms
Unlike below threshold where the client deems a hit and sends a claim to the server for server arbitration. Those that exceed the threshold have all shots fired arbitrated strictly by the server. Hit or miss every shot is scrutinized by the server.
Additionally shots fired and lost via packet loss are not resent by the client…for those with high latency and/or variance (jitter). Also late arrival of shots and extremely delayed client → server data are discarded… again for high latency players. Furthermore when a player’s client data is not received in a timely manner or at all, the server will extrapolate positional information about the player and bind it to the gamestate history.
A large portion of the player who won’t accept the physics of the internet and thinks its much fairer everyone else suffers the effects of there poor connection rather than them.
Or video. If it happens all of the time, it should be pretty easy to capture and post.
It’s kinda messed up to give those players an awesome experience, then take it away.
I hate it too, but it’s the reality. You can’t pull the rug out from people a year in, it’s unfortunate that the 100ms soft cap was bugged with no ping relevant extrapolation to even things out.
Because of a bug, we are stuck with 160ms/200ms. It is what it is, I will be very harsh with my network feedback for the next game, and for incursions, but the public servers don’t seem like they will become any less high ping friendly, even with continued optimization and a main focus on low ping play.
At least we are making progress, bf4 was revolting in this department, and DICE lied about things over and over, I haven’t forgotten.