i am creating a multi player iPhone game using the multi player tutorial as the skeleton in the following link http://www.raywenderlich.com/3276/how-to-make-a-simple-multiplayer-game-with-game-center-tutorial-part-12.
With the architecture i am using (GameCentre peer to peer)one of the devices plays the role of the server. I have a question, just what is the limitation of the packet size? On average i need to send out 890 bytes per go...
Generally you should not rely on the network packet size. The packets can get fragmented (via TCP/IP and get re-assembled by the stack) or data get packetized based on MTU of the sending/receiving parameters.
Per the Game Kit Programming Guide:
Limit the size of unreliable messages to 1000 bytes or smaller in size.
Limit the size of reliable messages to 87 kilobytes or smaller in size.
Related
I did several effects, and only on PC the fps fell from 170 to 80. What can be done to make it consume less resources? Is it possible to decrease the resolution
I need to check whether or not a device can support voip calls at a certain level of quality. My approach (of which I accept there may be a better one) is to conduct an Internet connection speed test on a user's iOS device immediately before the call is placed. The speed test should, as accurately as possible, determine whether the impending voip call will be of good or poor quality.
The voip call includes live video (similar to Skype).
I'm aware of the following techniques to measure connection speed:
Download or upload a file and measure how long it takes.
as outlined here. Will measuring download or upload speed give an accurate picture of what voip call quality will be like for the immediate call? Also, files may be cached or speeds may even be throttled by the ISP.
Use ICMP packets (ie. ping) a reliable server (eg. google.com).
One potential problem with this approach is that (I've heard that) some routers are configured to give ICMP packets a lower priority than others. Therefore they cannot be used as an accurate measure of bandwidth/speed/reachability etc. Is this so?
Is measuring network connection speed an effective way to predict voip call quality? If so, what is an effective and quick (ie. less than 3 seconds) way to measure Internet connection speed for this purpose?
The actual data of a VoIP call is carried over RTP, which really only takes 24-64Kbps (depending upon codec) and requires UDP addresses going each way. Occasional RTCP packets are sent to report status, metrics, etc, but are not really needed.
SIP is used for call setup and teardown.
The RTCP packets carry (minimal) call quality metrics.
Several parameters influence call quality, including choice of codec, available bandwidth, network latency, packet loss (RTP is over UDP so no retransmission), and jitter (inter-packet arrival delay, out of order delivery).
(Cicso) Switches implement RED, a technique to reduce queue depth by randomly discarding network packets. For TCP network connections, that is acceptable, because TCP has retransmission through a sliding window protocol. And many UDP based protocols implement application retransmission. But RTP does not afford that luxury. So random discard of voice packets impairs the connection quality. One solution to RED would be to tunnel VoIP over a TCP connection, but that wasn't the choice made.
Congested networks are a huge source of VoIP call quality problems, and that can be measured during the initial few seconds of a call. Dropped packets due to jitter and delayed packets (high network latency) are two main causes of call quality degredation. I worked on a VoIP quality of service monitor system, and we observed the worst calls had high jitter and high latency (above ~70ms is bad). Avoid high latency, congested networks. Choice of coded can have a huge impact on quality. Higher compression codecs lose more to packet loss than less 'efficient' codecs, so pick a codec that uses higher bandwidth (good luck).
IP networks need QoS guarantees to provide best VoIP quality. And until TCPIP is redefined to include QoS, VoIP will have (potential) problems.
Your approach is close. But you want to measure:
UDP
Packet loss
Congestion
Latency
Packet jitter
You need to timestamp and number your packets, and detect high latency, interarrival jitter, avoid measuring over TCP (packet retransmission will skew your quality numbers, and TCP reorders packets, even though it introduces delay). You also want to know the quality on both. You might find that codec selection would be a huge factor in improving the calls.
The company I worked for building the monitor (Telchemy) licensed their VQMon software as a product to measure quality, so the tool you want already exists.
I'm looking around to find the appropriate technology to implement an app that I've in mind.
Basically I am using bluetooth to estabilish a connection trhrough 2 iOS devices. In the first part of communication I only send messages, and everything works ok.
In the second part i would like to permit the user to share a video file; let's assume, for example, that the video file is 20 MB.
Now, what's the best option to transfer this large data through the 2 devices?
Can I use GameKit and split the data in small packet? It'll take a reasonable amount of time?
Or it's better to use Bonjour and wait that until the user'll be under the same wifi network or create a wifi network through the 2 devices?
Thanks in advance
In case someone else (like me) stumbles upon this question, I'll share my experience:
Bluetooth
Pros: You don't need wifi
Cons:
Apple only allows you to access the BLE interface, which is a lot slower than regular bluetooth. I tried this and it takes around 5 minutes to transfer 1 MB of data. Also, you need to chop your data into chunks of ~20 Bytes and make sure the files are received correctly on the other side.
GameKit
I haven't actually tried it, but it seems GK is fine to send small text messages (since it is designed for this), however sending larger files will still be pretty slow. Also, you can only connect 8 devices simultaneously.
Bonjour and Wifi
Pros: This is as fast as it gets. You can send reasonably sized files (a few MB) within a few seconds.
Cons: You need to be in the same wifi network.
Using a remote server
Pros: Assuming you have a decent internet connection it's reasonably fast and you are not depending on wifi (if you have 3G/LTE).
As it turns out this is pretty easy when you use a Backend-as-a-Service provider like Parse.
Cons: Well, you're gonna have to write that server software... Your app users probably need a mobile data plan.
I ended up with solution #3, using Bonjour and Wifi, since I didn't want to write server side code. If you want to do this, you need to learn about Socket programming. I suggest using CocoaAsyncSocket which uses TCP so you don't have to make sure you received the file correctly.
Since it is 2016 and Swift can be used in Obj-C projects, you can have a look at my solution, which will spare you almost all of the work: https://github.com/JojoSc/OverTheEther
It allows you to send any kind of object (implementing the NSCoding protocol) to another device.
I am making a small Online 2D RPG multiplayer game that uses a client-server architecture. I was reading up on the max bandwidth a client can receive from the server for I don't just kill players' connections, but am having a hard time finding real good data on google.
Currently updating the status of a player on screen takes 29bytes. I send an update every 100 ms, so that's about 300 bytes per second per player. I read that the Valve Source engine targets only 5-7KB/s. Whats a good safe limit I should shoot for, for I can catch all but the lowest bandwidth users.
Remember, 5 KB/s is 40 kilobits/second. 0.3kb/sec should be perfectly fine. Anyone still on dialup is going to be getting 56kb/sec (7KB/sec), and there aren't many people on dialup playing multiplayer games I'd imagine.
If I am writing my own networking services via Bonjour (instead of GameKit's implementation), is there any limit to the amount of devices that can connect to a single socket? Meaning, I have one device that is the "host", is there a limit to how many other devices can connect to the host via Bluetooth/Wi-fi?
The maximum number of remote users able to connect to the given host is dictated by the max number of file descriptors iOS allows you to open on a socket. It's not strictly a Bonjour issue. I'm unable to find any documentation for iOS but the default value for OS X is presently around 256 open descriptors per socket (low compared to other UNIXes, although it can easily be bumped).
Given the hardware constraints of an iOS device I would assume this max value is lower, but should still be in the hundreds, comfortably enough for gameplay between users on the same link-local network.
Get above that number of concurrent players and the likelihood is that CPU and network conditions would be the limiting factor anyway.