I have two two about BLE technology.
1)How to ensure the packet can be transferred under connected mode (FEC forward error correction??)
understand the impact of packet loss (in both broadcast & connected mode). For connected mode, if packet loss, will the packet error correction / sequence number / CRC will help to correct it and retransmit the packet?? For broadcast mode, any ack after receiving the packet by the Gateway or just keep transmit by the client device with the same packet information for a while??
I expeceted the BLE have the correction mechanism, but i am not sure
Related
I'm trying to emulate packet loss for my project. I'm using TCP/IP protocol. netem tool provides such functionality. The delay works in the loopback IP but I couldn't make packet loss to work. According to the website of netem, the packet loss is activated as follows:
tc qdisc change dev lo root netem loss 5%
In the client/server app using TCP/IP socket in c programming, the client sends this message "Echo this !", the echoed message from the server received by the client is intact. As far as I know, TCP/IP guarantees the delivery of packets. Is emulating packet loss impossible with TCP/IP protocol?
If the packet is lost, TCP will send it again after some delay. If it gets lost again, it will send it again. And so on, up to a maximum of 10 minutes or so, after which it just gives up.
5% packet loss is not completely terrible and your message is likely to get through after one or two resends - or zero. Also notice your whole message fits in a packet, so your programs only send a few packets in total (your message plus extra ones to connect and disconnect) and it's quite likely that none of them will be lost.
You can try sending a longer message (like a megabyte), and you can try cranking the packet loss up to 25% or 50% (or even higher!). It should take a lot longer to send the message, even without any delay in the network, but your message should get through eventually, unless TCP decides to just give up and disconnect you.
I'm devleoping a multi rx threads ethernet driver, but this may lead to potential issuse that delivery out-of-order packets to linux network stack. this issue has been verified on PPTP connection, because GRE has sequence number and will drop out-of-order packets.
So, does TCP has an tcp reassembly queue or similar mechanism to process out-of-order segment.
TCP has a window buffer. As packets arrive they are cached until the next expected packet sequence number is received. When the next expected packet is received (and it's valid), it's passed onto the application for receiving in order.
see https://www.quora.com/How-does-TCP-handle-the-duplicate-segments-and-out-of-order-segments
Is a multi-threaded client necessary in order to cause packet loss, if both the server and client are on the same machine ? What would be the case if there is a remote server ? Suppose I'm sending packets to the server from the client sequentially (in a for loop), is packet loss possible here ?
Can anone explain how it works when an application sends UDP unicast datagrams over an 802.11 WiFi network? Assume non-blocking UDP socket. For concreteness, assume 802.11n or 802.11ac and a reasonably new Linux kernel (Android Lollipop or Debian stable). Specifically, if the sender NIC does not receive any positive ACK of send MPDUs, will the send() call return -1 and socket send queue in kernel be shown as non-empty with netstat? And the NIC will re-send same MPDUs repeatedly?
If this is not the right place to ask, please point to a good reference or another StackExchange site maybe.
In my understanding. Wifi(layer 2) would NOT care about UDP/TCP protocol, for wifi hardware, it is just a frame,
the cast will act like this.....
frame sending -> no ack -> retry again -> no ack -> retry -> no ack -> retry ...
after a few retry, wifi hardware will drop this frame and send next frame in NIC buffer. wifi driver should NOT always keep this frame, because frame drop or lost is frequently case in wifi.
then we talk about UDP network protocol now, because it's anon-blocking UDP socket, UDP would not care any error, it just continue sending and sending and sending....
Android phone has a feature -- "miracast", it also use UDP as a video streaming protocol and use wifi to transfer data. maybe you can check how does this function work.
Layer-2 (Wi-Fi, in this case) knows nothing about the layer-3 protocol (IP, IPX, etc.) used, much less the layer-4 protocol (TCP, UDP, SPX, etc.) used: Wi-Fi doesn't know about IP, which doesn't know about UDP. The whole point of the network layers is that they are independent of each other. Wi-Fi can carry any layer-3 protocol, which, in turn, can carry any layer-4 protocol, which can carry any upper layer protocols.
I observed a surprising thing that when there are both udp-based and tcp-based applications sending packets, if the upd-based application sent the packets so fast that the bandwith are nearly filled with udp packets, then the tcp packets would be very hard to send out.
The surprising thing is that though tcp-based application is able to send a few packets out (observed by the return value of write()), the receiver of the tcp packets never receives them. Why? Is that because the tcp-packets arenot finally sent out by the network card? or the tcp packets are actually dropped by routers?
Thanks,
Steve
First, the return value of write() is not an indicator of whether packets were sent. It just indicates that the data was buffered.
Second, if you are saturating the network with UDP packets there will be a lot of packet loss, and TCP being adaptive will adapt to that by sending packets out more slowly. If the packet loss gets too high TCP can basically stop altogether. The solution is not to saturate the network with UDP packets.
This is a simplified answer. There are many articles you can read up on.
UDP is a layer built upon IP. Ditto for TCP. The network card just sends out IP packets. You can look up the various structures for these packets.
TCP is a protocol that uses IP packets but uses a mechanism to try to ensure delivery and rearranges packets in the correct order. See the article on Wikipedia.
Routers are free to drop packets. This can occur when the network is overloaded, network connections are down or the IP packet is corrupted.
So to answer your question their is no preference between UDP or IP to be transmitted from one end to the other.