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
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 5 years ago.
Improve this question
A packet contains an IPv6 header with no options and a 20-byte TCP header. Is the IPv6 packet here smaller than the Ethernet minimum packet size, and, if so, by how much?
Yes, the example that you give is smaller than the minimum Ethernet frame size; packet refers to things at Layer 3 and above, frames to layer 2.
The minimum frame size is 64 bytes. An Ethernet frame consists of 14 bytes of Ethernet header and a 4 byte trailer (Frame Check Sequence). This leaves 46 bytes (64 - 14 - 4). Note that you will not be able to see the trailer in any typical sniffer; the network card will not deliver it to the networks stack of the operating system.
The TCP/IP packet that you have described would be 40 bytes in length. This means that the remaining 6 bytes will consist of padding.
I leave it to you to apply the same logic to figuring out the size of an IPv6 header/packet.
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 6 years ago.
Improve this question
Let's say hypothetically that I have 3 devices that are all compatible and Bluetooth enabled.
Device #1 - A fitness watch of some kind that you wear on your wrist.
Device #2 - Arbitrary state device with master/slave BT chip(s)
Device #3 - Bluetooth enabled lights / decorations
Pairings:
Device #1 <-> Device #2
Device #2 <-> Device #3 (multiple of them throughout a room, maybe 5 or 6 Device3's)
Is there a way/easy way/accepted way to repeat the signal from #1 to all the #3s? I was hoping #2 could act as a hub maintaining state, but let the Bluetooth signal pass straight through to all the #3s (without #1 needing to directly connect to all the #3s individually).
What would be the best way to approach this kind of situation?
I think what I'm basically describing is like an Ethernet switch but for Bluetooth.
The short answer is "no", there is not an easy or standard way to do this. What you are looking for would be a Bluetooth repeater. Bluetooth repeater devices do exist, but are proprietary, not standardized. For example, this one from a German solar power manufacture, specific to their devices.
Usually, Bluetooth networks are a simple star topology with a single master and one or more slaves - a piconet. However, it is possible to join multiple piconets into a larger scatternet.
The longer answer is that it is possible, but will require software support from Device #2. That may involve custom software or firmware development. Depending on your application, it may be simpler to consider adding another form of wireless connectivity into the system, such as wireless Ethernet.
This may not be quite what you're looking for, but Aircable claims to have a device that will extend your Bluetooth range. I haven't tried it, but there's a review of an older version that indicates that it does work, though perhaps not as well as it claims. There's a (newer?) version available on Amazon.
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
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.