can multiple tcp sockets be marked as kCFStreamNetworkServiceTypeVoIP in a VOIP App? - cocoa-touch

I'm having some confusion if a VOIP App can have multiple tcp sockets monitored in background via kCFStreamNetworkServiceTypeVoIP option. Apple documentation says mark one of the sockets but doesn't say that multiple sockets can't be used.
My sample code with 2 tcp sockets seems to be working fine in background but wanted to confirm that it is not just some fluke and actually supported by iOS.

It does work, you can mark any (and as many) VOIP TCP sockets as you like. The 'use case' here would be if you have a VOIP client registering against multiple servers, each of those sockets would require a separate TCP socket, and thus have the VOIP property assigned.
I think the docs are actually referencing that you only need to set ONE socket per service you're registered against (as opposed to one per app).

Related

For UDP (Multicasts), multiple applications can subscribe to the same port. If one packet has arrived from client, which application receive it?

For UDP (Multicasts), multiple applications can subscribe to the same port.
If one packet has arrived from client, which application receive it?
Nowadays, mDNS discovery is very popular in LAN D2D use cases. Different applications may bundle different mDNS discovery modules, which leads to the fact that multiple applications listen to the same port. When one packet comes, which application receive it? Or all get notified?

When is an endpoint bundle-aware and when not?

From
Link: www.w3.org/TR/webrtc/#dom-rtcbundlepolicy
Content: 4.2.5 RTCBundlePolicy Enum
"If the remote endpoint is bundle-aware, all media tracks and data channels are bundled onto the same transport."
When is an endpoint bundle-aware and when not? And what does bundle-aware means?
To establish a p2p connection, WebRTC will allocate and do STUN network checks on up to 3 ports (multiplied by ways they can be reached) on either end, and as they're discovered (which takes time), ask JS to trickle-exchange info on each of these "ICE candidates" across a signaling channel, once for video, once for audio, and once for data (if you have it).
WebRTC does this mostly to support connecting to non-browser legacy devices, because all modern browsers support BUNDLE, which is when all but one candidate end up being thrown away, and all media gets bundled over that single port.
WebRTC even has a "max-compat" mode that goes even further, allocating a port for each piece of media, just in case the other endpoint is really old.
WebRTC doesn't know the other endpoint is a browser until it receives an "answer" from it, but if you know, you can specify "max-bundle" and save a couple of milliseconds.

Receive udp broadcast packets ios

I'm almost completely done with and iOS client for my REST service. The only thing I'm missing is the ability for the client to listen on the network for a UDP broadcast that receives the host display name and base URL for uploads. There could be multiple servers on the network broadcasting and waiting for uploads.
Asynchronous is preferred. The servers will be displayed to the user as the device discovers them and I want the user to be able to select a server at any point in time.
The broadcaster is sending to 255.255.255.255 and does not expect any data back.
I am a beginner in objective c so something simple and easy to use is best.
I recommend looking at CocoaAsyncSocket. It can handle UDP sockets well. I haven't tried listening to a broadcast with it, but it's probably your best bet.

Serverless P2P UDP chat

What is the most simple and straightforward approach for serverless P2P UDP chat in Boost Asio? The chat will work across the internet. There are ready UDP examples but they all maintain client-server approach!
I'm assuming that by serverless you mean a P2P network without a central control server.
IMO your question has little to do with boost-asio. asio is a cross-platform network library. You seem to be asking more of a network engineering type question and asio is just one of the tools you can use for implementation.
The examples are client-server in that the example applications possibly fall under the client-server architecture. However the socket code (or asio usage) used to send and receive messages will look the same irrespective of client-server or P2P applications i.e. you send a message to an address and you receive messages on a specified port. The differences will come in at the protocol layer, but this has nothing to do with asio per se.
The following may or may not be of interest to you: there is no simple way IMO: users located behind firewalls and NAT means that you need to use techniques such as STUN, TURN and ICE to resolve addresses or in the worst case relay data. All these designs require a server.

How to find a locally available UDP port with unix Sockets API

I have an application where I have potentially many processes must send a message to one process. I figured the most expedient way to do this would be to just send a UDP datagram.
When opening a socket, I need to specify which port to listen to. As I just want to fire and forget the UDP datagram, I'd like to just have the OS pick an available port. I'd rather not have to hunt for one, especially as many instances of my process may be running. Is there a way I can tell the OS to just pick an available port (or better yet, not even open a listening socket) to fire and forget my UDP datagram?
Yes. Specify 0 as the port. The OS will pick an available port for you.
Answering the "Problem" rather than the "Question"
If all the processes are operating on the same PC, you might want to look into shared files or some other means of communications other than a networking stack.
I'd suggest you explore the options in Boost's Interprocess library
http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess.html
Quick guide here:
http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/quick_guide.html
Specifically, I suggest you use a named pipe or shared memory between your processes.