Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
TCP and UDP(sometimes) use a simple checksum to make sure the contents are correct.
What I want to know is any empirical data or estimate, of how often a packet is corrupted, but has the correct checksum for a person with a standard computer and internet connection.
Now I know that this probably all varies widely with ISP quality, hardware quality, and more, but I just want to hear any information on this.
You're asking how long a piece of rope is. In general, unless there's something wrong, the error rate should be less than 10-7. On the other hand, wireless, 3G, and such can have significantly higher error rates.
This Google search will show you there's a lot of literature.
From Microsoft Research,
Traces of Internet packets from the
past two years show that between 1
packet in 1,100 and 1 packet in 32,000
fails the TCP checksum, even on links
where link-level CRCs should catch all
but 1 in 4 billion errors. For certain
situations, the rate of checksum
failures can be even higher: in one
hour-long test we observed a checksum
failure of 1 packet in 400. We
investigate why so many errors are
observed, when link-level CRCs should
catch nearly all of them.
http://academic.research.microsoft.com/Paper/22436.aspx
Basically transmit 100MB+ over a typical Internet connection and you are very likely to see a silent failure.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I have just been refreshing my networking knowledge and came across a question regarding packet (segments, frames .. does not matter really).
There are many diagrams of the packet or segment header on the internet and its quite understandable. How are but these fields ordered in a binary stream flowing through cable and how does translator figure out that one packet has ended and another begins while just receiving ones and zeros?
Thanks
Understanding this requires understanding the OSI 7 layer model.
If you want to specifically talk about data flowing through a cable, and assuming you mean TCP/ IP data over Ethernet, then Ethernet is a layer 1 & layer 2 protocol. How the data is physically transmitted depends on whether it's full or half duplex, whether it's 8 wire, 4 wire or 2 wire (though 2 wire protocols are propriety like EtherCAT) and other such physical transmission concerns. Typically, a PHY chip sits at either end of a cable and passes up Layer 2 data to some kind of MAC layer.
Anyway, getting to the point regarding when does a listener know when a packet starts and finishes, the ethernet protocol defines a 7 byte preamble and start of frame delimiter and a 4 byte Frame Check Sequence. You can read more about it here.
Software to process packets that runs on a CPU will typically never see any of that though. Ethernet frames will pass their payloads into a buffer where it will be stored sequentially until it's read or overwritten.
Simply to say, one of the Protocol in handling these process is TCP (Layer 4) protocol, which sends the split data with index as 0,1,2,3 and in receiving side obviously it may receive in order 3,1,0,2 or in order 1,2,0,3 or any other but the TCP append data by index
I explain in Layman point
Study about the OSI Reference Model and Networking basics
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
When 3 Duplicate Acks arrive TCP halves its congestion window, but when only 1 or 2 Duplicate Acks arrives what does TCP do ? Does it increase the congestion window like any other non duplicate Ack ?
That reaction to 3 duplicate acks is in TCP Reno. When it receives 1 or 2 duplicate ACK's it shouldn't do anything. The increase of the congestion window occurs after original ACK's are received because they indicate the communication is good and TCP is tries to get to the maximum possible throughput.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
so ive read this post here: and im a bit confused, so here's my additional question:
how does UDP handle data which are lost? because it says there that UDP doesn't care if the data will arrive to the destination or the ordering of data.
SO example in an on line game, how does UDP handle data loss? my understanding is that when a data is lost so lets say my character's hand cant be seen in an on line game? or the warglaive of azinoth which i farmed for years is lost? LOL
and if the ordering is not important so lets say i the head of my character will be messed up or the body will be dislocated, something like that.
So can anyone clarify this for me?
A better example of UDP in gaming is for position information.
In this case the position of a character is sent several times a second and it doesn't matter whether a packet is lost as another one will be sent again shortly. When you combine this with a game engine that does some level of interpolation and extrapolation then you can achieve smooth looking motion from sporadic data.
In the case of re-ordering if you receive a character position which is older (in time) due to packet re-ordering you would just discard it as you've already got a newer value.
With your example of loot - it's possible this information is sent via TCP or using a reliable wrapper around UDP - to your client.
Take a look at http://code.google.com/p/lidgren-network-gen3/ for a C# UDP networking library which is designed with games in mind. It provides various unreliable and reliable channels over UDP and should give you an idea how UDP is typically used in games.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about programming within the scope defined in the help center.
Improve this question
I've been asked in a assignment to analyze a packet trace and determine what kind of VNIC the user has on his or her machine. I'm finding this to be quite difficult however; I'm not quite sure what to look for. I'd appreciate getting pointed in the right direction. I mean whether the connection is through ethernet or a wireless 802.11 card
If you have the capture file with you already then open the file with wireshark, and on the display filter type "wlan", then click Apply to filter out 802.11 packets. The display filter expression for ethernet is "eth". If there are any packets on display after you apply the display filter, then there were packets that used the protocol. You can look into the packets with Wireshark to see the ethernet II or 802.11 header.
You can download some sample captures of 802.11 and Ethernet II from http://wiki.wireshark.org/SampleCaptures.
Do you mean the manufacturer of the Ethernet/WLAN card? The first 6 bytes of the Ethernet address are called the Organization Unique Identifier, and you can look them up here:
http://standards.ieee.org/regauth/oui/index.shtml
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I know it's possible to modify the IP headers and change the source IP address, but it should be simple for network devices to detect and discard those messages. If they don't, why not? Does it add too much overhead?
The industry name for the feature you are asking about is called "Unicast Reverse Path Forwarding" (or as Cisco calls it, "uRPF"); it is defined in RFC 3704 and is considered a Best Current Practice (see BCP38).
Speaking at a very high level, most of the hardware used by ISPs has this feature built into an ASIC; normally there is not a huge penalty for turning it on. Sometimes there are feature conflicts, but again this is not a huge deal in most cases.
The biggest reason it isn't universal is because the internet is still somewhat like the American "wild west" in the 1800s; consider them analagous to a town's sheriff. The policies and competency of the engineering/operational personnel varies, and many ISPs are too busy with making things "work" that they don't have cycles to make things "work well".
That dynamic is particularly true in smaller countries; I worked for a large network equipment manufacturer in a previous life and occasionally traveled throughout southeast asia conducting ISP seminars. Smaller countries are often half a decade (or more) behind the practices and competency of ISPs here in the US (that's not to say that US ISPs are terribly great on the whole either, but they are generally much better off than, say, some of the ISPs operating in the smaller islands in the Pacific).
This results in the non-trivial amount of spamming / hacker traffic on the internet today... it's there because they have no lack of places to hide. Source IP address spoofing is one of their first lines of defense.