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).
Related
I was looking all over the internet to find a way to capture incoming packets from a certain network interface, then I came across PCAP, TCPDUMP, I believe the most commonly used networking library out there is Boost/Asio, so I wanted to use this library in order to capture traffic, but apparently there is no example for using Raw sockets or other classes to listen for incoming packets to a certain NI, I would appreciate any help or examples on this.
We eventually found out the best option for sniffing incoming packets was Libtins.
libtins is a high-level, multiplatform C++ network packet sniffing and crafting library.
Its main purpose is to provide the C++ developer an easy, efficient,
platform and endianness-independent way to create tools which need to
send, receive and manipulate network packets.
It uses a BSD-2 license and it's hosted at github.
Is WebRTC going to be free for web developers to set up video calls on web pages?
why does Twilio having pricing 25c per mins for video calls,
is it going to be too expensive for the small guy to mange video calls on web hosting servers?
any advice from anyone deep into WebRTC already?
Some of the comments above are not well informed.
Someone wrote, since the bandwidth needed in case of media relay is higher as well. This is not entirely true, transmission happens between Peers(Browsers), servers are used just for signalling(relaying IP addresses of connecting peers and some more info), you can ROUTE your transmission from central server(for fail overs), but can surely do without it for free.
WebRTC is Free and you can setup the whole thing on your own without having to shell out even a penny. It is a bit hard and mitigating fail-overs is really difficult, but you can certainly do it for free.
Tokbox or Twilio charge money because these tools abstract some very rigid complexities of setting up, running and managing fail-overs in a WebRTC application.
In TokBox's Case:
You don't need to setup STUN, TURN servers, you don't have to worry
about integration with android or IOS clients, they provide a plugin
for IE too, so out of box you get everything and you just have to
concentrate on your application logic rather than WebRTC nuances.
This is a big plus.
Both RELAY and ROUTED schemes came in the box hence you can write
fail-over scenarios if RELAY communication fails. Although there are
some good JavaScript based frameworks that do this in a much cleaner
manner.
It adds slew of other goodies which help in building android and IOS
clients without any pain.
STUN or TURN Servers are used only for Signalling Purpose, and this signalling happens before any actual transmission. This signal is very small and carries the IP address of both the browsers(machines running browsers). For Transmission the communication is done between Browsers(Peer to Peer) themselves, so no server is involved.
Your relay is not happening from a central server so you don't have
to pay for the outgoing bandwidth cost.
To Setup Turn Server,
Use this server, build it and put it into a Rackspace/Amazon Web
Services instance and you are Good with your TURN
Server. That is It, setup your application and have fun with WebRTC
for FREE.
rfc5766-turn-server
If you wish to Use some more free framework to ease yourself more, check out: EasyRTC and PeerJS
Enjoy Developing with WebRTC....
Twilio developer evangelist here.
Your link at the end of your question points to our WebRTC page, which currently talks about the product Twilio Client. Twilio Client briefly is a way that, using WebRTC within browsers and mobile applications you can make phone calls to real phone numbers. This product does not allow you to conduct video calls.
Twilio Client has a cost because of the ability to call out from a browser to a telephone number. The cost is not in the WebRTC portion, but delivering those minutes to the other leg of the call.
Notably, it's not 25 cents ($0.25) a minute, instead it is just a quarter of a cent ($0.0025) a minute.
With regards to video calls with WebRTC, you can now access the public beta of Twilio Video, a platform to make setting up WebRTC calls much easier.
Twilio Video costs for the signalling infrastructure and you can see the prices here. If a WebRTC connection requires a TURN server to relay the media, that also costs per gigabyte of transfer. Usage of the STUN server is free, the costs for the TURN relay are available here.
Please get in touch with me at philnash#twilio.com if you have any other questions about WebRTC.
WebRTC is a technology placed in a browser. It requires backend infrastructure to support it - specifically, STUN and TURN servers as well as signaling servers.
This boils down to the fact that you pay for WebRTC - same as you pay for hosting your website on a server. The price is higher, since the bandwidth needed in case of media relay is higher as well.
To understand more about WebRTC and how it works (as well as why there's a price tag associated with services such as Twilio for it), you can check this free report: https://bloggeek.me/webrtc-business-people/
WebRTC is already free for developers to use. When we added WebRTC to our product, we used this example code, which made it very simple to build a WebRTC client:
https://shanetully.com/2014/09/a-dead-simple-webrtc-example/
Google and Mozilla provide free STUN servers, and it is easy to set up a TURN server. Most clients will be able to connect via STUN, so you won't end up using too much bandwidth on your TURN server.
To set up your own TURN server, coturn seems to be the easiest to set up:
https://github.com/coturn/coturn
Make sure you read the "WEBRTC USAGE" section in the README.turnserver file.
"STUN or TURN Servers are used only for Signalling Purpose, and this signalling happens before any actual transmission. This signal is very small and carries the IP address of both the browsers(machines running browsers). For Transmission the communication is done between Browsers(Peer to Peer) themselves, so no server is involved."
if that is the case, then you should be able to do this on a standard web server using Java/php. PHP will get the IP address of the guys connected to it. Then its just a matter of storing them in MySQL, then making a javascript that would run when the user go to that page in the site.
I've been looking for a solution around using a VPS because running a dedicated server for signaling is like golfing with a Ferrari instead of a golf cart. I still don't think node is efficient. Its single threaded. so node's fararri can only go 5mph.
Since they went to the web site, the php service already can get their ip address what else does it need? All of the above solutions so far require you to pay for a dedicated app to run on a server connected to the web separately for what 5k of data? What a waste of electrons.
But I'm going to start a new thread that is going to be based on getting webrtc without the buy a "VPS" because we want a VPS-less solution.
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.
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
I am working on a project that involves an embedded system which runs a non-microsoft OS with a C program for the application and am developing .NET software for its end user applications. For remote configuring with the .NET software (which can go across firewalls), I am considering using WCF. I know only a little about WCF so far but I've read that it is supposed to be interoperable with environments other than .NET. The embedded environment has an HTTP stack but no built in support for web services. Does anyone have any experience with this kind of thing or know if it would be appropriate at all? If so please provide some advice or point me in the right direction.
Thanks!
WCF is interoperable because it's accessed over HTTP. Visual Studio can help you build client libraries very quickly for WCF, but client access to WCF doesn't require anything other than HTTP calls with the proper payload. If you're looking at a remote server call and your built-in support in your embedded environment is basic HTTP, look at building your server-side as REST-formatted methods. Your debugger will thank you.
What kinds of data are you planning on transferring back and forth? For something this low level and proprietary I would recommend sticking with good old fashioned Sockets.
I will be passing configuration data back and forth...basically to enable technical support staff to remotely program the device. If I were using sockets this could be binary data, but there is a requirement that customers with firewalls shouldn't need to open any ports. Because of this I was thinking of sending XML over HTTP. So, is it better to use WCF or REST on the server side? Or WCF with REST?
I'm curious about your "customers with firewalls" requirement. Sockets with binary data or XML over HTTP can use any port (not just port 80), and I'm curious if your device will be "listening" on the network, or just making an outbound connection. If your device is listening, you will need to open a port on the firewall. Making an outbound connection ("phoning home") is much easier on the firewall.
So I think you could use sockets and binary data. However, I have faced similar issues on the last two projects, and I really wanted to implement WCF using REST on the embedded device, but no one else wanted to do it - I'm hoping someone else will be first, and publish some results!
Good Luck! (and post your results!)