Having read the announcement about google nearby 2.0 it's clear that WiFi connections are supported.
Nearby Connections uses WiFi, Bluetooth LE & Classic Bluetooth under the hood to discover and establish connections to nearby devices.
Or from the docs overview page
Under the hood, the API uses a combination of Bluetooth, BLE, and Wifi hotspots
What I'm not clear on is whether the WiFi support is exclusively when devices are connected to the same WiFi router, or whether the service will also use WiFi P2P (aka WiFi Direct) to establish connections when possible.
My experience using similar services on other platforms is that bluetooth connections can often be too slow for fast paced multiplayer games. My title already supports connections over WiFi routers, so ideally I'd want the service to add WiFi play in the absence of a router.
I think my question is answered in the I/O talk about Nearby Connections refresh (link).
We connect over bluetooth and start transferring data instantly, but
in the background we also bring up a WiFi hotspot, and when that's
ready we seamlessly transfer your connection from bluetooth to WiFi
with absolutely no work required by the app developer
I'm reasonably confident from the context that the WiFi hotspot they're talking about is an Adhoc/Direct/P2P one (not sure of the correct terminology, but mobile to mobile WiFi of some sort) rather than a physical router.
The announcement says
At I/O this year, we spoke about a refresh to the Nearby Connections API that can provide high bandwidth, low latency, encrypted data transfers between nearby devices in a fully-offline P2P manner. Today we're announcing the availability of this API across all Android devices running Google Play services 11.0 and up.
Its fully offline and P2P so it looks like that there is no need for them to be connected to the same wifi router.
Related
can anyone help me what is the technical difference between WebRTC communication and the VoIP communication?
The question doesn't exactly make sense because it makes the assumption that VoIP is a technical stack, but it's not - it's a concept. The concept of sending Voice (V) over (o) Internet Protocols (IP). This means that different technology stacks can be used for accessing/capturing the media, establishing connections, negotiating streams, and transmitting streams.
WebRTC is one such stack (set of APIs, methods, and standards) for VoIP.
VOIP - Voice over Internet Protocol was a concept which came with popularity of internet. This involved using the internet to route voice telephony data, basically using existing IP infrastructure to transport audio streams without having dedicated circuit switched telephony. Over the time popular VOIP applications like Skype, Vonage and many in enterprise telephony came in.
VOIP had two parts one signalling , basically controller part and other actual media.
Actual media usually but not necessarily followed RTP (Real Time) protocol. RTP could carry both voice and video. Problem with RTP has been that browsers don't support it natively and it is not secure. You usually needed some sort of plugin to have VOIP work inside browser.
With WebRTC now popular browsers like FF, Chrome and Opera support a variation of RTP which is secure and can be natively invoked. Using WebRTC and browser Javascript you can send Voice, Video and Screen (it's video only) data to any other browser, which is cool.
VOIP : Voice over internet protocol uses DSL/Cable Modem voice over Wi-Fi/3G (VoWiFi/3G), voice over LTE (VoLTE), and Rich Communication Suite (RCS). VoIP is cloud-based, calls are sent as digital data and no cables are needed to send the call so any kind of Internet connection can be used to make calls and from a plethora of devices.
Web RTC: Web Real time communication use only OS browsers to communicate.
WebRTC requires the use of two main component JavaScript APIs.
WebRTC is an extension of VoIP to the browser world. It can reuse the existing VoIP infrastructure with incremental upgrades. This is good news for VoIP, as adoption of WebRTC only serves to increase overall VoIP proliferation.
Also, WebRTC is ideal for low-cost browser-based contact center applications. VoIP can serve embedded operator-driven VoLTE applications. Consequently, between WebRTC and VoIP, they can support wide range of consumer and enterprise applications.
I've been looking through the API docs and support forum. Based on what I've been reading, there are two big holes in the Sony camera stack:
1) Cameras ONLY support master mode (peer-to-peer) wi-fi connections. They do not support infrastructure mode allowing the camera to connect to existing wi-fi networks.
2) API does not support moving files off the camera.
My questions: Does Sony plan to address add these capabilities? If yes, what is the timeline?
Thanks,
Graham
Thank you for your interest.
(EDITED: multi Wi-Fi connection is used by Live View Remote LVR & Camera Remote API is officially NOT supported in multi Wi-Fi mode).
Sony lens style cameras QX1, QX30 and ActionCams HDR-AZ1, HDR-AS100V can connect to existing Wi-Fi networks (Multi Connection Wi-Fi mode). Please check if your Wi-Fi network is compatible with connection method used. Newer QX1, QX30, HDR-AZ1 cameras support content transfer API. Please check API Reference document for exact APIs. Best Regards, Prem, Developer World team.
I have 2 iOS devices and an application which starts or connects to a NSNetService.
When both devices have have bluetooth turned on the data stream will automatically be done over the bluetooth interface.
I do not want that, i want both devices to communicate over the WiFi. Is there a way to force a NSNetService to communicate over the WiFi?
Thanks
I don't think there is, I haven't looked into the docs, but I know a ton of games recommend disabling Bluetooth and ensuring WiFi is enabled for local multiplayer.
Preferably, this would be a computer connected via cable, but if there's a way to do it over wifi then this would also be useful. I'm wondering if it's possible to send messages between them?
Or if i had a mac app and an iPhone app, could I communicate between them over wifi or a usb connection, rather than using a server or something?
Connecting over WiFi is possible, cable connection however isn't possible (certainly not in the documented API) unless the phone is jailbroken.
For wifi you're just going to connect to a TCP/IP host/socket. Have a look at CocoaAsyncSocket. The computer would need to be hosting some sort of server software. This is how iTunes Remote and AirMouse work.
There are some "permitted" (non-cracked phone) ways to send data to the iPhone from a device that's physically plugged in. There are several barcode readers - like the Linēa-pro used in US Apple stores - and magstripe readers for credit cards (e.g., the Macally Quikswipe) that can send limited amounts of data to/from the iPhone.
If your computer is a small embedded device and your data requirements are meager, it may be possible.
I have a Nokia Symbian Series 60 3rd edition phone. I can use it as a GPRS / 3G modem either using Bluetooth, USB or IR.
Is there a way to programmatically detect when the phone is being used as a modem?
Please note I don't want to detect when a GPRS / 3G connection comes up (such as when you use the phone browser), but when a GPRS / 3G connection comes up that is the result of the phone being used as tethered modem via BT / IR / USB.
So the user has set up a dial up networking connection on their laptop, for instance, which uses the modem in the phone. They then launch that connection because they want to make a 3G wireless internet connection from their laptop via the phone. That's what I'd like to be able to detect from the phone.
I don't believe there's any public interface that you could use for this. You could probably use internal APIs to check what is creating the data connection, or more crudely check which processes are running when a data connection is created - probably quite easy to fool this method, depends why you want to know?
I can see network operators wanting to do this to block and/or charge extra for tethering usage. Easiest way to do that would be network side though, checking the browser UA header (also possible to fool, but not without harming your browsing experience a bit on the laptop).