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.
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 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
Does anyone know of a programme that can take a wireshark (pcap) trace and turn it into a visual network topology?
I have 3 pcap files with "ALOT" of data and I really want to see if I can make sense of some things.
I played with things like network miner but nothing that can give a visual cue to the data. For instance
You are in fact asking two questions:
How to discover the network topology from network traces
How to visualize the discovered topology
Topology Discovery
This is the hard part. The community has not yet have developed reliable tools, because network traffic exhibits so much hard-to-deal with crud. The most useful tool that comes to mind in this space is Bro, which creatse quality connection logs.
It is straight-forward to extract communication graphs, i.e., graphs that show who communicates with whom. By weighing the edges with some metric (number of packets/bytes/connections), you can get an idea about the relative contribution of a given node.
For more sophisticated analyses, you will have to develop some heuristics. For example, detecting routers may involve looking at packet forwarding behavior or extracting default gateways from DHCP ACK messages. Bro ("the Python for the network") allows you to codify such analysis in a very natural form.
Graph Visualization
The low-key approach involves generating GraphViz output. Afterglow offers some wrapping that makes the output more digestible. For inspiration, checkout out http://secviz.org/ where you find many examples on such graphs. Most of them have been created with afterglow.
There is also Gephi, a more fancy graph visualization engine, which supports a variety of graph input formats. The generated graphs look quite fancy and can also be explored interactively.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Describe each mode.
Give examples of protocols that implement the various modes of TCP/IP operation.
Full-Duplex allows for communication in either direction at any time.
An example is HTTP Pipelining.
Half-Duplex allows for communication in one direction at one time then can switch to the opposite direction.
An example is the POP3 Protocol (as well as FTP, NNTP, SMTP).
Simplex allows for communication in one direction only and doesn't allow switching directions. This is sometimes specificed programmatically as Simplex Server or Simplex Client.
A simplex line permits data to flow only in one direction. doesn't support switching direction.
A half duplex line can alternately send or receive data but only one at a time.
A full duplex line can send and receive data simultaneously.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am working on getting the performance parameters of a tcp connection and one these parameters is the bandwidth. I am intending to use the tcp_info structure supported from linux 2.6 onwards, which holds the meta data about a tcp connection. The information can be retrieved using the getsockopt() function call on tcp_info. I have spent lot of time finding a good documentation which explains all the parameters in that structure, but couldn't find one.
Also I tested a small program to retrieve the values from tcp_info for a tcp connection where I found the measured MSS values for most of the time as zero.To make long story short-Is there a link to follow for which has complete details ontcp_info and also is it reliable to use these values.
Here is a fairly comprehensive write-up of the structure and use of the linux tcp_info by René Pfeiffer but there are a couple of things worth noting:
The author needed to look at these data repeated over time because there are no aggregate stats in that structure.
The author directs you to the tcp.c source as the final authority on the meaning of any of those data.
I'm not sure what you were hoping to get from the Maximum Segment Size, but expect you thought it meant something else.
If you are truly interested in exact measurements of bandwidth you need to use a measurement device which is outside the system being tested as even pulling the ioctls will affect the phenomenon you are interested in knowing about. A passive wire sniffer is the only way to get truly accurate results. Finally, depending on your application, "bandwidth" is a really broad umbrella which flattens many measurements (e.g. latency, round-trip-time, variability, jitter, etc.) into one category.
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.