On my mac I have two kinds of networks available - Ethernet, WiFi.
While making a server call, can I somehow control which network channel to use for making the server call? So, before making server call, I want to specify the network channel to be used for that call - Ethernet or WiFi.
How can this be achieved using objective C. I am working on a cocoa application.
I assume both NIC's are connected to Internet (so both have a IP):
I don't think you can solve it within code (not 100% sure). But what you could do is setup some local routes, configuring which traffic goes over what NIC.
Look at the route command ('man route').
This might help you:
https://serverfault.com/questions/100613/public-traffic-to-go-over-1-nic-and-private-traffic-to-use-another-nic
You can modify the routes available with the System Configuration framework. In scutil(8) you can see the routes that are presently installed in the State:/Network/Service/* dictionaries, and in order to manipulate these programmatically you have to us the SCDynamicStore framework, which is C.
However, if you were trying to just do some ad-hoc service on WLAN only, you could use the CoreWLAN framework, which is in Objective-C.
Related
I tried to build a server for integrating the webrtc native APIs in an native app, but I am not sure about how the server should be configured, like the ICE/STUN/TURN, signaling, media server etc..
So far as I know is the open source project: https://github.com/priologic/easyrtc
Can anybody give some recommendations?
Thanks
In a WebRTC infrastructure, there are several things involved. The client part is written in JavaScript and runs on the browser.
But as you said it is a server side part. First there is a ICE/STUN/TURN server that it's used for a client to discover its public IP address if it is located behind a NAT. Depending on your requirements could not be necessary to build/deploy your own server, but use an already public (and free) existing one - here's a list. You can also deploy an open source one like Stuntman.
Then it comes the signaling part, used by two clients to negotiate and start a webrtc session. There is no standard here and you have a few options.
You can use an XMPP server with a Jingle extension. You can deploy an existing XMPP server, like OpenFire or Tigase
You can also use SIP, a protocol much more encountered for VoIP. You can use JAIN-SIP or SIP Servlets.
Or you can develop your own signaling protocol using something like websockets.
The server side options that I was giving you were Java based ones, but you can find similar for other infrastructures too.
STUN/TURN is required. Use public ones (not absolutely stable) or get a Ubuntu machine ans install from the source: https://code.google.com/p/rfc5766-turn-server/
Signaling is trivial. You just forward messages between peers. Just build a simple chat server.
Media server is whole different story and require sophisticated client-server configuration.
I writing a mac application and i need to discover other Macs/PCs/iPhones/iPads connected to the same WIFI network.
Bonjour seems to be the most reasonable choice, but it turned out that it has problems on many types of routers (on mine for example, is not working as it blocks Bonjour services).
I just need to find iPs of devices, then i will try to connect to an application-specific port to determine if my process is running there.
What is the best approach to accomplish this task, without violating the App store Sandboxing?
ARP was the first answer which came to my mind. Does your network-setup allows this?
I am attempting to build a client/server game architecture and would like to begin testing the game using my local Mac as the server. I have found several articles on Bonjour, but that is for local network traffic only. My goal is to make this application work over the Internet, connecting to a hosted application on a static address to facilitate turn data. However, I'm at a loss as to which Cocoa APIs to use for this purpose. Should I use NSConnection, NSStream subclasses, or good 'ol C sockets and whatnot. The game state is already built in Objective-C and is ready to be set in motion once I have the server facilities ready. Any insight?
NSConnection, NSStrean and C sockets are build for different needs. You need to specify the needs of your game and the kind of service in order to get more help. If you want to develop a client-server application that relies on the Internet and not on the local network, Bonjour will not be able to help.
C sockets, and Cocoa APIs that wrap around them are intended to operate on an open network stream between the client and the server. The advantage of having an open stream is that you can have the server send data to the client without the client having requested for it. NSURLConnection in Cocoa works differently. With it, you can perform HTTP requests and receive formatted responses from a server.
If your application is based on HTTP requests, I recommend you take a look an NSURLConnection, or AFNetworking, as a 3rd party alternative. If your application relies on open streams, I recommend you take a look at CFNetwork from Apple (C wrapper around BSD sockets that originates from the days Macs had Carbon, with great performance, stability and versatility) and GCDAsyncSocket, a 3rd party library wrapped around BSD Sockets, supports Crand Central Dispatch, is Objective-C ready, and does the job wonderfully.
I hope I helped.
I suggest you to use sockets, since they're not hard to use and are a standard way. I've even written an asynchronous wrapper class around BSD sockets: https://github.com/H2CO3/TCPHelper
This is for simple, one-to-one TCP protocol connections, supporting both IPv4 and IPv6. You can send and receive raw NSData and possibly build a protocol around it.
Foundation classes such as NSURLConnection are not particularily for this purpose; rather than to interact with standard HTTP servers (I suppose you don't want to implement a full HTTP server for a game).
NSNetServices may suit you just like CFNetwork, but the latter is a bit harder to use. If you'd like to use Foundation classes, I'd recommend NSNetServices.
Hope it helps.
There are many different ways to accomplish this. It really depends on how you'll be passing the data and what it will be used for.
First, I would setup a hostname that you can use for development purposes with your game. You can use anything like http://dyn.com/dns/ to setup this for your Mac. Then you can enable a compiler setting to switch out the development / production URL's.
Next, I would recommend using TCP sockets for your game (using CocoaAsyncSocket - https://github.com/robbiehanson/CocoaAsyncSocket). This method should work fine your your use case. Since you are doing turn-based data (and since all of that data is vital) I would not recommend using UDP sockets (but those would work if you were solely passing position, video, or audio data where a dropped packet might not matter).
I am relatively new to iphone development. I have looked through the documentation and cannot really find an answer to this problem.
I have a server which I have created and know the ip address and the port it is using. I am now trying to connect to this using an iphone application I am creating. Through the documentation there are many example where it connects via an ID (such as the witap example) however there is none where it directly accesses a previously created server.
Would anyone be able to point me in the direction of an example that uses this, give me some information or even inform me of another way around doing this? It would be much appreciated. Thanks.
Bonjour is a technology to detect servers in your local network. If you already know it, as you seem to because you know the IP address, you can connect to it using the usual techniques.
It depends on your server, is it a HTTP server? There are some Cocoa classes that might help you.
If it's a custom made server you might consider CFStream or raw sockets.
I am working with an electronics appliance manufacturer to embed LAN based control systems into the products. The idea is to serve up a system configuration/control interface through a web browser so clients never need to install software. We can communicate with the appliance by sending and receiving serial data through the embedded module. Since the appliance can also be controlled from a front panel UI, it creates a challenge to keep a remote web interface in sync with very low latency. It seems like websockets or some sort of Push is what we need for handling real time events from the server to clients.
I am using a Lantronix Mathport AR embedded device server. Out of the box the unit will serve up any custom HTML and java servlets/applets. We have the option to install a lightweight Linux distro if we need more flexibility. I am not sure how to implement any server side apps since the device is not running standard Apache. I believe it is using Boa.
Can anyone guide me in the right direction of how to do this?
Some general info...The WebSocket protocol (draft spec here) is a simple layer on top of TCP. What this means is that, if you already have a TCP server for your platform, implementing the WebSocket is just a matter of hours. The protocol specifies a handshake and two ways of sending data frames.
I strongly suggest you start by reading the 39 pages spec.
As Tihauan already mentioned, start by reading the spec, and also note that there are still some changes ongoing, although websockets is now more stable than it was 1 year ago.
Key point for me was the requirement that websocket data is entirely UTF-8 text, which lends itself nicely to JSON based message definitions.
Our system uses a form of embedded linux, so we then added and made use of the following libraries:
"libwebsockets" from:
http://git.warmcat.com/cgi-bin/cgit/libwebsockets/
"jansson" from:
http://www.digip.org/jansson/
Using the above as support libraries, we created an internal lightweight "client/server" that allowed our other software modules to register for certain, applicable, websocket messages, and respond as needed. Worked great.
Good luck and best regards,
I'm a bit late, but Mozilla posted a guide entitled "Writing WebSocket servers", which literally guides you through writing a websocket server.
You will need to already know how HTTP works and have medium programming experience. Depending on language support, knowledge of TCP sockets may be required. The scope of this guide is to present the minimum knowledge you need to write a WebSocket server.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers