My app send message to server then wait for reply, over udp. But there are random packet loss.
I want to detect packet loss by timeout, how can I do it in swift?
I cannot find it from doc.
Related
I developed a C++ app to stream video from a webcam on an Odroid device over UDP. The client is an iPhone app using simple UDP sockets and it works perfectly over Wi-fi, but not over LTE. The sendto() call works okay, but the recvfrom() blocks forever. First I thought it has to do with iPhone blocking UDP traffic, but I also tried a client on my laptop connected in the iPhone's hotspot and thus over LTE.
Do you think there is something with phone providers blocking UDP traffic?
I preferred UDP instead of TCP for faster streaming.
Any advice would be highly appreciated!
Thanks!
UPDATE: I found the cause of the problem after some further inspection. It turns out that UDP over LTE sets the IP_MTU_DISCOVER flag and if the user's packet is larger than the device's MTU, it does not perform IP fragmentation but simply drops the packet. My application is sending packets larger than MTU, but in the case of Wi-fi they are fragmented in the IP layer. If you disable the IP_MTU_DISCOVER flag, the large packet is fragmented and arrives successfully in the destination. The other alternative would be to send packets smaller than MTU from the application. Both approaches do not perform that well, but at least the mystery is solved.
I'm facing a wired situation in sip calling using Portsip sdk. While I'm using dtmf method INFO and stop processing both incoming and outgoing audio during sip calling I can hear the dtmf tones. But when I'm using dtmf method RFC2833 and stop processing both incoming and outgoing audio, I can't hear the dtmf tones. I want to know, if it is the default feature of INFO and RFC2833.
With SIP INFO, DTMF is sent out-of-band, as part of the SIP dialog, so you don't need to be processing the audio streams to receive it. With RFC2833, DTMF is sent in-band, in specially marked RTP packets, so if you are not receiving or processing the audio streams, you will not hear DTMF either.
As a simple example, using SIP INFO and the default port for SIP, you would be getting your DTMF on UDP port 5060. Using RFC2833, you would be getting it on whatever epheremal port was negotiated for the RTP stream, e.g. UDP 20542.
Here is a brief introduction to the different options for sending DTMF with SIP
I am now writing a program which should be able to dynamically select and switch 802.11 channels. Multiple threads can use a shared 802.11 radio. The goal is to let a thread lock the radio before switching channel, and then transmit one data packet, finally, unlock the radio after the data packet has been successfully transmitted out of the 802.11 NIC or dropped permanently.
But I can't find a way to know if a data packet has been transmitted out of the NIC card or it is still somewhere in the host. I am programming in C on Ubuntu. I use UDP socket to send the data packet. A successful return from "sendto" doesn't indicate that the data packet has been successful transmitted out of the hardware.
Could anyone point out a way to receive notifications of packet delivery status from 802.11? To sum up, I want to receive notifications when a data packet has been transmitted out of the NIC for broadcasting mode, and when a data packet has been successfully received by the other end or has been permanently dropped for unicast mode.
Any answer will be appreciated!
I am new to socket programming and don't have much idea on how it works, Here is the use case, Im developing an iPhone app, where users stream real time audio originated from another iPhone device (in short Multi casting)
What I have done so far:
I opened a port on server which keep listening to incoming data from clients. On the iOS side, i implemented methods thats read the packets received on the server and process it accordingly (i have used GCDAsyncSocket)
Problem where I need help:
The above use case works perfect for 2 users, one that sends the audio data to the server and the other one reads that data to play audio. But actually there would not always be a single user originating audio data, they could be more than 100+, Now when all of them are sending different audio data to server how could i filter data for the listeners that everyone receive only there data, I overcome this problem adding a token on every packet like
unique_token:<ffdefa09 fedead3...... //Audio Data
But this process is way too slow as every client is listening all the packets and only process the ones with the token they are assigned.
Is there anyway, we can make a peer to peer connection by which the originating device become server and only sends data to its listeners and don't bother anyone else?
Can't you add something like a light protocol before you start steaming audio data to server ?
iPhone -> server [Request: Start Stream Audio]
server -> iPhone [OK: TCP Port:4444]
// iphone sending audio packets to port 4444
iPhone2 -> server [Request: Start Stream Audio]
server -> iPhone2 [OK: TCP Port:4445]
then the server can filter all audio channels with TCP port ID instead of packet ID (or maybe I misunderstood your issue)
Btw I don't think you can do any "real" P2P with iPhone on cellular networks because of providers firewalls
for every end who send the audio data, you create a socket and recv audio data, and for every end who receive the audio data, you create a socket and send audio data.
P2P is lots of work , because many device are behind the public address.
You need to separate your command data from your streaming/audio data.
First you need the iphones to tell the server what they want,
iphone 1: "i want to stream this data with id 1"
iphone 2: "i want to listen to stream with id 1"
that way the server can tell the iphone where to connect for getting the data it needs, as HaneTV suggested with port numbers
Im currently developing a chat client for the iphone.
Server-side there is a node.js with Socket.IO and on the iPhone an Socket.IO client
( https://github.com/DanLite/socket.IO-objc )
My Question is:
Will the iPhone battery affected with an open TCP connection and not sending or receiving data for like 3-4 Minutes?
What is better for battery life? A constant tcp connection or multiply HTTP requests.
Thanks
Edit:
I have a chat + other functions like (changing name, checking friends status, edit settings)
Edit 2:
Looks like WhatsApp doing it with a tcp connection
When TCP connection is opened both parties posses information about it (remote ip:port, local ip:port). That information is a mere data structure in the memory.
As long as there is no RST packet received or timeout occurred connection is considered to be opened.
When you send data over connection you start consuming CPU and force underlying wireless mobile network module to send signal hence consume battery.
That is why it is better to keep TCP connection for as long time as possible and prefer batching over chatty communication (combine several application messages).
On the other hand you should be prepared to the situation when network coverage is poor and you will have to constantly reopen TCP connection thus consume battery.