Is there a way to make use of iPad/iPhone's socket capabilities without using Objective-C? Is there any way to expose this functionality with ActionScript 3 or some über HTML5 framework?
On the Arduino forums I'm trying to find out my hardware limits, here and here (I found out that using Objective-C this would be possible, even with bonjour discovery).
(With webSockets, or with UDP. It doesn't have to be Haxe.)
I'm researching the possibility of using webSockets, which should be the easiest if it's possible.
However, I'd like to consider all options. So I know Arduino can talk raw UDP. And I know that there is a CocoaAsyncSocket library for Objective-C. Only, I'd like to NOT prototype in Objective-C...
(So, this will be the n-th post on Stack Overflow about a Wi-Fi-enabled Arduino that I'd like to talk to an iDevice. Bluetooth is not an option due to Apple's non-prototyping-friendly-MFi-program.)
You can use the C POSIX socket API (probably easiest, if you know C). Or you can use HTML5/Javascript and Haxe or socket.io.
Related
I am working with some network code on my client that connects to a server using BSD-level socket APIs (connect(), etc.). My program is written in Objective-C and platform is iPhone
I want to add SOCKS-proxy support to this, but I have not been able to find any way to do this at the BSD level. I have seen code that does this at the CFNetwork level, but I'd rather not rewrite all my networking code for this.
If anyone knows how I can add SOCKS client support at the BSD level, please let me know.
UPDATE: I am pretty sure I could implement the SOCKS protocol myself, but I'd like to avoid that if possible. Is there any 3rd party libraries that are recommended for this (hopefully open source)? They would have to be able to plug into my existing BSD-level socket code.
I'm trying to write a simple DPI (Deep Packet Inspection) tool. In my current phase, I need to develop a H.323 protocol detector. To aim this goal I need a H.225 / H.245 packet generator. I seems that almost all tool use SIP and RTP & RTCP protocol. Does anybody have any idea which tool use H323 protocols in VOIP?
There is number of h323 libraries, some of them are openh323 and openoh323/openooh323.
But ALL libraries have issues and alot of bugs. Main issue - protocol is VERY complex if compare with sip or other modern protocols and ALL vendors do "vendor-specific" addons/changes in protocol way they think "better for client".
As result it is hard to work with any tools. Easy way detect is just get signatures like 'h323', 'rtp' etc.
As a final school-graduation project I try to develop a kind of spying-car. Which means there is an iPhone placed on a little LEGO-car and an iPad used as a "steering wheel" for the car. Also it is planned to transmit Audio and Video from the iPhone's microphone/camera to the iPad (more than the steering data vice versa).
In the first place the connection from iOS to iOS should be established over a local WiFi network and later - if possible - over 3G (by using the iOS devices network-IP and a DNS server to deal with frequently changing addresses).
My question is: which technology do you recommend using? I read about GameKit, peer-to-peer and so on, but I think these technologies are too abstract for later being able to communicate over 3G. I guess I need to go a little deeper into the low levels of the communication progress. Any suggestion that could bring me a step forward is highly appreciated! (also regarding other parts of my project)
One more thing: Some user suggested using a third party service and to route the sent (video) data over an external server. If possible, I'd rather not use any "middle man". It should just be a basic server-client communication where the iPad is the server and the iPhone the client.
It is kind of an open ended question, but interesting.
First of all, GameKit do have 3g p2p support, see here:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/GameKit_Guide/Matchmaking/Matchmaking.html
It will handle the peer-to-peer addressing and establisment of the socket. It can also handle voice chat, but I personally never tried this feature so I can't say if it is feasible in your case.
One idea is to leverage existing video-chat services. This will give you a low-latency audio/video channel with peer-to-peer addressing (well, likely using a central server).
Apple's FaceTime is such a service, but there is no public API to it (AFAIK). Same goes for Skype and Google.
There are some paid services that look like they have nice iOS APIs:
http://tokbox.com/platform
http://docs.weemo.com/sdk/ios/
You have to figure out a way to transmit control commands to the peer iPhone, I did not see if the services above had any possibility of sending text messages/arbitrary data.
Tokbox has a free trial so you could try it out and see if it works for you.
I would go for GameKit if this is a hobby project on a budget and there is time for hacking, and probably look into a more high-level API if there is a deadline...
sorry for writing this as an answer, but i don't have enough rep to comment...
i'm working on a similar project and i currently don't have any advice regrading video-streaming, however, from what i read (extensively) i came to the conclusion that i need to use p2p connection between devices for better performance and use socket programming in order to achieve this (although not the most easy to implement choice).
I considered using GameKit which i think will probably answer most of your needs as Krumelur pointed out. but in my case, eventually the app will be cross platform so i had to use low level network programming. you can check out my question here to see the sources i used to try and make the connection between 2 peers, hopefully you'll have better luck than me...
I would like to understand the way SWIFT messages work. I tried to understand from Google and it says that it uses packet switched network mechanism.
It would be of great favour if somebody can throw light on the following questions
Whether SWIFT by itself a communication protocol like AS2
For Trade finance system if I use IMEX does using a SWIFT message requires any Adapter kind of components with IMEX
Architecture of SWIFT
How SWIFT works is a big subject, but it's basically a proprietary protocol driven by the needs of the SWIFT community.
Since it all started in the early days of computing, the core stuff uses the UNIX philosophy of: write programs to do one thing, do it well, and use text as your inter program communication.
So, to take FIN messaging, SWIFT works using ASCII text files across a secure network.
To be able to send and receive these text files you need to join SWIFT. See http://www.swift.com/ordering/join_swift
The architecture is proprietary, but, once you join SWIFT you can send and receive specifically formatted text files, or, in the "next generation" it's XML but, to me, that is trying to re-invent the UNIX philosophy, which is bound to fail, and be very expensive in the process. But apparently this is what clients wanted...........?
So there you have it...
I'm looking to replicate the Instashare functionality (for a simpler, more specialized task, that of exchanging notes between multiple people who are in close proximity to each other).
I'm not sure where to start with this, both from an architectural stand point, but also from a development stand point.
What I assume so far is that I would need to create an internal network between 2 devices (e.g. make all devices both clients and servers), then keep some sort of a connection opened on all of them.
Is this correct? Could it be a better way to do this? What frameworks could I use for this?
You can use GKSession and GKSessionDelegate (Tutorial) for sending the files over Bluetooth back and forth. For sending over just Wifi you would use TCP and something like CocoaAsyncSocket and/or SocketKit.
BTW, Seems like a great weekend project. Kudos for wanting to tackle it ;)
Other related question on SO:
Building a Server/Client application in Cocoa