I have client/server application. Client on iPhone, the server on the Windows-based machine. First, I establish a connection to my server and that works fine. When I go away from WiFi area - client disconnects (is's expected).
But, when I enter into WiFi area again and tried to connect to the server, the connection is established but the client doesn't receive any data. I need restart my client application to connect to the server.
Why did it happen? This happens always when I'm sending data in both directions with about 1 Mbit/s.
I'll be thankful for any idea =)
Thanks
When you leave the Wifi area, Tcp detects that you have no connection, so the server will drop the Tcp connection. You have to reestablish it when you get back in Wifi range.
I am not an expert in this area, but maybe there is a time limit, within which, if you reenter the Wifi, the existing Tcp connection is reused?
However, to be robust, you should always code your app to retry, if operating in Wifi is one of your main scenarios.
Your TCP has gone into a long timeout trying to get the data through on a link that doesn't exist for a while. You need to detect this happening, close the socket, and reconnect.
Or, switch to using UDP if you don't actually need TCP's reliability (although this isn't its proper name, think of UDP as the 'Unreliable Datagram Protocol', in other words there's no guarantee of delivery, nor of delivery in the correct order).
Related
I had an issue today where a client was getting a busy signal when dialing in or out. They have a Cisco phone system and their provider is Cox who uses an edgewater devices to convert the internet traffic to SIP traffic.
I accessed the BE6000 router/gateway and pinged the HP switch that has the phone system connected. I had one timeout and then it's like the connection between the router and the switch woke up. Is it possible that the connection on the uplink from the switch to the router wasn't communicating until I sent that ping request? As soon as I did that and it started communicating I was able to call in and they could call out.
Just seeing if that was a coincidence or had any significant impact.
Based on the information provided, there is no way to determine the cause why the Phone system was down. However, I can confirm that the switch would not be sleeping and come up after you ping it. It is not how switches work. The reason why your first ping timedout and received response on second one is most likely due to arp request and response, which is normal between hosts that haven't communicated directly with each other for sometime (arp timeout).
There are some ios sip applications who are able to communicate with a UDP only SIP Server.
As I know iOS allows only TCP connection to remain open in the background but most of the SIP providers are supporting only UDP.
I have noticed that iOS application 3CXPhone has a "NAT helper mode" and it is able to keep the communication in background with a 3CX Phone system who is UDP only. Dose anyone know what trick do they use? I am developing an SIP app and I have to make it work for the UDP only SIP providers.
I know there are multiple questions regarding UDP socket in background on SO but none of them has a useful answer or the solution proposed there dose not work anymore (starting from iOS 6).
Until now I am aware of 2 possible solutions:
1. Use some GPS events and during that events maintain the socket communication too. After that try to trick apple and get your app in the store.
2. Use a SIP proxy in the middle (B2BUA). But in the 3CXPhone "NAT helper mode" I am not seeing any sip proxy configuration.
If you really need a UDP socket you will need a few things:
UIRequiresPersistentWiFi: to ensure that iOS connects to Wi-Fi and doesn't turn it off after some time (I'm assuming you want Wi-Fi as well, if not just ignore this one)
Play an empty audio in the background in a loop to keep your application active.
Have a timer that pops every ten seconds or so and sends a small (e.g. crlf) message to the server.
The last step is needed to keep the UDP connection open in the network. If you don't send anything often, someone in the network (e.g. a router) will close it.
The empty audio file is the only way to ensure you can do something in the background in short intervals (the ten second timer).
After writing all that: this will consume a lot of battery. Users will not leave your app running for long.
Most modern SIP servers support TCP. You should really spend your time on a TCP solution. The UDP one won't be accepted by your users.
I'm working on my multiplayer game for wp7.
At this moment i successfully implemented the multiplayer game on Udp on UdpMultiCastClient.
Well, without the phone itself i cannot test it, but from other various site(SO included) it seems UDP packet won't cross over outside of the router. So I wanted to implement a TCP P2P, so each game client connects to everyone else, so data wont be proxied through server.
But the socket class on WP7 doesn't have Listen method, neither AcceptAsync.
Is it normal?
It unfortunately seems like you can't bind a WP7.5 socket to listen for incoming connection on a specific port. So the phone can't act as a server. This is really a shame. TCP P2P connections would be awesome.
Hopefully this will be implemented into next version of Windows Phone. Meanwhile the easiest solution is probably to use a server in the middle which both devices connect to.
Edit:
Socket Listeners is available in WP8.1 ...
https://msdn.microsoft.com/en-us/library/windows/apps/hh202858(v=vs.105).aspx
https://msdn.microsoft.com/en-us/library/windows/apps/hh202874(v=vs.105).aspx
Im currently developing a chat client for the iphone.
Server-side there is a node.js with Socket.IO and on the iPhone an Socket.IO client
( https://github.com/DanLite/socket.IO-objc )
My Question is:
Will the iPhone battery affected with an open TCP connection and not sending or receiving data for like 3-4 Minutes?
What is better for battery life? A constant tcp connection or multiply HTTP requests.
Thanks
Edit:
I have a chat + other functions like (changing name, checking friends status, edit settings)
Edit 2:
Looks like WhatsApp doing it with a tcp connection
When TCP connection is opened both parties posses information about it (remote ip:port, local ip:port). That information is a mere data structure in the memory.
As long as there is no RST packet received or timeout occurred connection is considered to be opened.
When you send data over connection you start consuming CPU and force underlying wireless mobile network module to send signal hence consume battery.
That is why it is better to keep TCP connection for as long time as possible and prefer batching over chatty communication (combine several application messages).
On the other hand you should be prepared to the situation when network coverage is poor and you will have to constantly reopen TCP connection thus consume battery.
I need to send and get packets via UDP and TCP in iPhones and the server. But, I figured that if I wanna send packets to a client (iPhone), he is... A kinda server.
So, let's say I'm sending and getting packets to iPhone via the port 2347. Do I need to open the port on the iPhone or something like that? Is there any Firewall built-in to the iPhone?
No firewall on the iPhone. However, 99% of the time, the phone will not have a publicly accessible IP. It may be on wifi behind a router, or it may be on the cellular network most probably behind a NAT pool. Either way, you don't have access to any of those pieces of equipment, nor do your users in the cellular context (and potentially some cases of wifi usage). Think about doing this another way.
There is no firewall on the iPhone by default. Provided you don't need the iPhone to act as a server, i.e., bind a port, you can have the server send packets back to the iPhone using the information in which they were received, i.e., IP and port, using the protocol of your choosing, e.g., TCP or UDP.