I am trying to implement a sort of chat between multiple IPhones, where one IPhone serves as a server and the rest connect to it. I have a main server which the rest of the phones get data on the connection, but I am not sure what data to send.
I know the IP of cellphones is highly dynamic, and I am not sure how to track the change of the IP and how to connect to it, and keep the connection while the IP changes.
I have read a bit about GCDAsyncSockets and know ho to listen to connections, but it still requires a static IP. Is it even possible? I mean I read around and it sounds like it is possible, but I really have no Idea how.
Related
My app tries to determine the IP of a web server located on the same LAN when it starts up.
It works out the IP range to scan, and uses NSURLConnection objects with a 1 second time out to determine whether an IP is reachable, and if it is, try to call a service on it, if the service call is successful then we know we've found the correct IP.
The problem though is that the app cannot open more than 5 connections at a time, even though all the connections have different IPs to connect to. I would get about a dozen connections firing off but the rest will just report The request timed out. without ever leaving the device.
I have read that this restriction applies to NSURLConnection connections to a single IP address, but as I said, each connection has its own different IP.
I have also tried using the SCNetworkReachability to determine whether an IP is reachable but all it tells me is that the IP addresses on the LAN are reachable, in theory, without making an actual connection.
Are there reliable ways to connect to more IPs at a time?
Every operating system maintains a maximum number of sockets per process. I couldn't find an authoritative source for iOS, but it would make sense for Apple to keep that number very low and five seems to be a common answer by others trying this.
You may want to look at NSOperationQueue to manage the connections (see Asynchronous HTTP Client Using NSOperationQueue) or use AFNetworking to do all the real work.
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
so I'm making an iOS app, but this is more of a general networking question.
So what I have is one phone that acts as the server and then a bunch of phones connect to the phone as the client. Basically it's a game/music sharer.
It's kind of hard to really get into the semantics of it, but that isn't important.
What is important is that the server and client are repeatedly sending each other commands and positions rapidly over a TCP connection, and sometimes the client wants to send the server a music file (4MB usually) to play as the music.
The problem I initially encountered was that when sending the large file, it would hang the sending of commands from the client to the server.
My naive solution was to create another socket to connect to the server to send the file to the server, the server would check the IP of the new socket, and if it has the IP of an existing connection then it would just tie it to that connection, receive the file, and then disconnect the socket.
But the problem with this is that it takes a 1-2 second delay for the socket to connect, and I'm aware that there are man-in-the-middle attacks that can occur.
Is there a more elegant solution to this problem?
I would not call your solution naive, this is largely how FTP works, separating data and control paths is a good design pattern in my view.
I wouldn't worry about the man in the middle thing. If you wanted, you could add a command to the client that it responds to over the data connection with a secret the server supplies, this would let you associate the connections without using the ip addressing.
If the delay is a problem then why not establish both connections at the start, the overhead of a few tcp connections on an operating system is not usually significant.
You could also use the two connections for both commands and data, alternating between them. Since both the server and client know when a connection is busy they can choose to use the idle one. The advantage of this is that it will keep both connections busy to ensure they are both known to be working.
You probably should also use a different thread for each socket but I suspect you are doing this since it won't work too well without it.
I'm in need of some advice for how to accomplish something.
I'd like my iPhone app to listen for information from my server and then my server will send out data to all listening devices.
A few questions:
Will the iDevice need to "register" with the server with its IP? So, then on the server side, I store all listening device IPs in an array and fire out data to each.
Is there away for it to simply listen without the initial message?
Is UDP the way to go on this? Obviously I don't want a TCP stream because it's a constant connection. Uses too much data. My goal is use the least amount of data possible to receive a small timestamp from a server.
Any suggestions would be appreciated!
Elijah
If you do not want to use Apple Push Notifications, and you don't want to use long polling, I would look into something like websockets.
PHP has a very good implementation for it (I assume PHP is your server side language?) in Ratchet.
EDIT:
Just to elaborate a little, WebSockets will allow you to transmit from the server directly to the apps of every connected user at once, just like you are asking.
I want to write a app which will run on different computers and need all of then to communicate with each other like "utorrent" (peer to peer). This app only will send text messages.
How can I do this? I mean sending one message to remote computer on the internet?
I have a website and every app at start can send some information to it and find information of other apps on other computers (with PHP) but I do not know how address one computer through internet and send the data directly to that. I can find the ip address with PHP but it is the ip address of router (ISP).
How a message reaches a computer? I'm wondering about addressing every computer?
My brain really stuck here, I really appreciate any help. Thanks.
In a peer-to-peer network there's no centralized server for transmitting the data from one client to another, in this case the clients must be able to act as both the server and client. This means that either you'll have to be using UPnP like most modern torrent clients, which handles port forwarding in the router, or you'll have to manually forward a port to the computer in the router.
A centralized server (like a torrent tracker) is usually used to make the clients aware of each other's existence and tell them where to connect. This is where your PHP script comes in, though PHP might not offer the most effective way of doing this, assuming you're using it in combination with a webserver to serve the data though the http protocol.
As for actual text communication, you could use the Indy socket library for that. I found this example, basically which shows how to do it: http://www.ciuly.com/delphi/indy/indy-10-client-server-basic-demo/