TCP connection to service on android 127.0.0.1 IP?
1,802 views
Skip to first unread message
myrealemai...@gmail.com
Feb 1, 2015, 12:46:08 AM2/1/15
to comman...@googlegroups.com
I wrote a custom TCP server app that sits on my Galaxy Tab 3 and listens
on port 55000 with the IP address of 127.0.0.1, i.e., the localhost
address of the device. I am able to communicate with it using another
app that I developed to test is. Everything works fine in this case and I
have been able to hit breakpoints in Android Studio without any
problems.
I setup a TCP client in the iViewer System Manager with the address 127.0.0.1 port 55000 (see the snapshot of the configuration dialog below), however, I never hit any of the breakpoints that I have set in Android Studio for the service. It looks like I never actually get a connection from iViewer as I have rebooted the device (the service starts at boot and stops on screen off, then starts again on screen on). The service starts, and I connect the Android Studio debugger to the service. I then start the iViewer app, yet no breakpoints at all are hit when the connection is made. This is in contrast to hitting the breakpoint where a connection is made from my test app.
Any thoughts as to what might be going on here? Is there a true TCP connection with the host device when specifying an address of 127.0.0.1?
In my current setup, I cannot count on having a wifi connection that is active such that I could connect this service to the wifi address and let the service listen on that address.
Thanks.
I setup a TCP client in the iViewer System Manager with the address 127.0.0.1 port 55000 (see the snapshot of the configuration dialog below), however, I never hit any of the breakpoints that I have set in Android Studio for the service. It looks like I never actually get a connection from iViewer as I have rebooted the device (the service starts at boot and stops on screen off, then starts again on screen on). The service starts, and I connect the Android Studio debugger to the service. I then start the iViewer app, yet no breakpoints at all are hit when the connection is made. This is in contrast to hitting the breakpoint where a connection is made from my test app.
Any thoughts as to what might be going on here? Is there a true TCP connection with the host device when specifying an address of 127.0.0.1?
In my current setup, I cannot count on having a wifi connection that is active such that I could connect this service to the wifi address and let the service listen on that address.
Thanks.
Jarrod Bell
Feb 1, 2015, 9:32:01 AM2/1/15
to comman...@googlegroups.com
127.0.0.1 systems will by default be
configured as "loopback" systems in iViewer, which never reach the
network stack.
These systems are designed for simple logic enabling commands to be sent and feedback to be parsed locally for a variety of reasons.
So if you want to enable something like this, you should use 0.0.0.0 as a TCP Server in iViewer and have your Android app act as the client.
These systems are designed for simple logic enabling commands to be sent and feedback to be parsed locally for a variety of reasons.
So if you want to enable something like this, you should use 0.0.0.0 as a TCP Server in iViewer and have your Android app act as the client.
--
You received this message because you are subscribed to the Google Groups "CommandFusion Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandfusio...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
myrealemai...@gmail.com
Feb 2, 2015, 11:01:38 AM2/2/15
to jar...@commandfusion.com
Hi Jarrod,
Thanks for your reply. I was thinking the situation was something like what you described.
I will give your suggestion a try. Right now, the android server app will continue to try restart and connect even if exceptions are thrown, so if iViewer is not available when the app tries to connect (which will definitely cause an exception to be thrown), it should connect when iViewer becomes available.
If you are interested, my situation is this:
I have a CF LAN Bridge and an IR Blaster.
My HTPC runs windows and has a WiFi card that acts as an access point when the PC is not hibernating. My Galaxy Tab connects to the network through this WAP.
The Galaxy Tab 3 has an IR Blaster, and the service I wrote gives access to the IR Blaster.
When the HTPC is on, then there is no problem as the network is available to the Tab through the HTPC hosted WAP; however, if the network is not available, this will mean that the HTPC is not running. In this case, my plan is to use an IR rule on the CF IR Blaster and trigger that with the Galaxy Tab's IR Blaster - the IR Rule would WOL the HTPC and turn on other components like my receiver and my display.
Thanks again. I'll let you know how I make out.
Thanks for your reply. I was thinking the situation was something like what you described.
I will give your suggestion a try. Right now, the android server app will continue to try restart and connect even if exceptions are thrown, so if iViewer is not available when the app tries to connect (which will definitely cause an exception to be thrown), it should connect when iViewer becomes available.
If you are interested, my situation is this:
I have a CF LAN Bridge and an IR Blaster.
My HTPC runs windows and has a WiFi card that acts as an access point when the PC is not hibernating. My Galaxy Tab connects to the network through this WAP.
The Galaxy Tab 3 has an IR Blaster, and the service I wrote gives access to the IR Blaster.
When the HTPC is on, then there is no problem as the network is available to the Tab through the HTPC hosted WAP; however, if the network is not available, this will mean that the HTPC is not running. In this case, my plan is to use an IR rule on the CF IR Blaster and trigger that with the Galaxy Tab's IR Blaster - the IR Rule would WOL the HTPC and turn on other components like my receiver and my display.
Thanks again. I'll let you know how I make out.
myrealemai...@gmail.com
Feb 3, 2015, 10:21:56 AM2/3/15
to comman...@googlegroups.com
I tested this last evening, and it looks like it will work. It shows up in the CF debugger as being on IP 127.0.0.1.
Is there the possibility that this will work in reverse? I.e., I setup the android service to connect to 0.0.0.0 which, before the WiFi network comes up, will likely put the service on 127.0.0.1, and then setup a client in CF to connect to 0.0.0.0? Will CF simply look for the IP address that has the associated port?
The main reason that I am asking this is that the connection attempt to CF in the service is in a loop. Each time the loop fails it throws an exception that is caught, and it is logged. Since it is running on its own thread, there is a 100ms sleep in their right now to limit the connection attempts to 10/second, but I have concerns about the logging and the possibility of filling the log or something happening if the log becomes too full that may cause problems with the Tab. When the service acts as the server, it simply waits until a connection is established, there is no timeout, so no exceptions are thrown.
If it is not possible to do this in reverse, I'll limit the logging to maybe one in ten (who knows what might be logged that may be important) as well as leave the thread sleep in there.
Thanks again.
Is there the possibility that this will work in reverse? I.e., I setup the android service to connect to 0.0.0.0 which, before the WiFi network comes up, will likely put the service on 127.0.0.1, and then setup a client in CF to connect to 0.0.0.0? Will CF simply look for the IP address that has the associated port?
The main reason that I am asking this is that the connection attempt to CF in the service is in a loop. Each time the loop fails it throws an exception that is caught, and it is logged. Since it is running on its own thread, there is a 100ms sleep in their right now to limit the connection attempts to 10/second, but I have concerns about the logging and the possibility of filling the log or something happening if the log becomes too full that may cause problems with the Tab. When the service acts as the server, it simply waits until a connection is established, there is no timeout, so no exceptions are thrown.
If it is not possible to do this in reverse, I'll limit the logging to maybe one in ten (who knows what might be logged that may be important) as well as leave the thread sleep in there.
Thanks again.
Jarrod Bell
Feb 3, 2015, 9:34:40 PM2/3/15
to comman...@googlegroups.com
0.0.0.0 is a special case for TCP
Server systems, meaning "Allow incoming connection from anyone".
It will not work for TCP Client systems (I believe it might even
convert it to a loopback system that bypasses network stack
completely).
I'm not sure why you would need logging for this connection, as it's only two options: works if the app is open, fails otherwise. Maybe can reduce the reconnection time considerably as well.
Sorry there is no perfect solution in this, very uncommon, case.
I'm not sure why you would need logging for this connection, as it's only two options: works if the app is open, fails otherwise. Maybe can reduce the reconnection time considerably as well.
Sorry there is no perfect solution in this, very uncommon, case.
myrealemai...@gmail.com
Feb 4, 2015, 1:42:54 PM2/4/15
to comman...@googlegroups.com, jar...@commandfusion.com
Hi Jarrod,
Thanks for your responsiveness. I have been known to do the uncommon thing from time to time. It keeps things interesting.
I spent some more time looking at this as I was going to implement it according to your suggestion.
What I found is that it works either way, but with one caveat in that iViewer will only accept the connection when (in server mode) or initiate the connection (when in client mode) if the WiFi connection is established. As long as I don't put the Tab to sleep, it also still works if I turn off the WiFi adapter in the Tab once the connection is established.
With iViewer was in client mode, I reverted the service code to use the localhost address so that it was waiting on 127.0.0.1:55000. I set the TCP client up in iViewer to connect to 0.0.0.0:55000 and once the WiFi network was available, I got the connection when running the service in the debugger.
Since my WAP is not guaranteed to be on at startup, I will not be able to do it this way. At this point, my work-around will be to use an app to start things up by sending an IR code to trigger an IR rule and then have that app launch iViewer.
I also have a provision in the service to monitor the ambient light sensor. We briefly communicated about this around a year or so ago, and I have found that in my HT room, there seems to be enough resolution to the sensor readings to distinguish between lights that are on in the room and ambient daylight, and keep the lights from toggling on and off randomly.
From my viewpoint, at least, it seems to be a valid use case for an iViewer user to want to be able to at least transmit IR from host devices that are capable of doing so.
In addition, I understand the utility of the loopback connection.
Please pardon me for pointing this out, however, in my opinion, specifying an IP address in a system where it will never connect to the IP stack seems to be somewhat of a departure from standard networking. In the java class for Android that provides IP addresses, there are two functions: InetAddress.getLocalHost() and InetAddress.getLoopbackAddress(). The return from getLocalHost() will fall back to the loopback address if it cannot get the localhost address. Beyond that, most operating systems do have an IP stack available when specifying the address 127.0.0.1.
From my viewpoint it would be nice to have the ability to specify that 127.0.0.1 is to connect to localhost rather than the loopback address through, perhaps, an added type of System in System Manager or a switch in the dialog. To me, it seems that such an option would simplify setup of a loopback in that the IP address and other details could become redundant if loopback were its own system type or switch in the System Manager dialog. However, outside of whatever changes might be made to iViewer to support that, there would have to some sort of versioning on the guiDesigner files to not break everyone who currently employes a loopback system - at least from my viewpoint; my developer side sees that it might be easier said than done.
The other "nice to have" for me would be the ability to use the IR emitter on host devices that have one. On Android at least, it is pretty straightforward to use through ConsumerIrManager (if one is present), and with some minor processing in API 19 and beyond, CCF codes can be used.
Thanks again.
Thanks for your responsiveness. I have been known to do the uncommon thing from time to time. It keeps things interesting.
I spent some more time looking at this as I was going to implement it according to your suggestion.
What I found is that it works either way, but with one caveat in that iViewer will only accept the connection when (in server mode) or initiate the connection (when in client mode) if the WiFi connection is established. As long as I don't put the Tab to sleep, it also still works if I turn off the WiFi adapter in the Tab once the connection is established.
With iViewer was in client mode, I reverted the service code to use the localhost address so that it was waiting on 127.0.0.1:55000. I set the TCP client up in iViewer to connect to 0.0.0.0:55000 and once the WiFi network was available, I got the connection when running the service in the debugger.
Since my WAP is not guaranteed to be on at startup, I will not be able to do it this way. At this point, my work-around will be to use an app to start things up by sending an IR code to trigger an IR rule and then have that app launch iViewer.
I also have a provision in the service to monitor the ambient light sensor. We briefly communicated about this around a year or so ago, and I have found that in my HT room, there seems to be enough resolution to the sensor readings to distinguish between lights that are on in the room and ambient daylight, and keep the lights from toggling on and off randomly.
From my viewpoint, at least, it seems to be a valid use case for an iViewer user to want to be able to at least transmit IR from host devices that are capable of doing so.
In addition, I understand the utility of the loopback connection.
Please pardon me for pointing this out, however, in my opinion, specifying an IP address in a system where it will never connect to the IP stack seems to be somewhat of a departure from standard networking. In the java class for Android that provides IP addresses, there are two functions: InetAddress.getLocalHost() and InetAddress.getLoopbackAddress(). The return from getLocalHost() will fall back to the loopback address if it cannot get the localhost address. Beyond that, most operating systems do have an IP stack available when specifying the address 127.0.0.1.
From my viewpoint it would be nice to have the ability to specify that 127.0.0.1 is to connect to localhost rather than the loopback address through, perhaps, an added type of System in System Manager or a switch in the dialog. To me, it seems that such an option would simplify setup of a loopback in that the IP address and other details could become redundant if loopback were its own system type or switch in the System Manager dialog. However, outside of whatever changes might be made to iViewer to support that, there would have to some sort of versioning on the guiDesigner files to not break everyone who currently employes a loopback system - at least from my viewpoint; my developer side sees that it might be easier said than done.
The other "nice to have" for me would be the ability to use the IR emitter on host devices that have one. On Android at least, it is pretty straightforward to use through ConsumerIrManager (if one is present), and with some minor processing in API 19 and beyond, CCF codes can be used.
Thanks again.
Jarrod Bell
Feb 4, 2015, 9:49:40 PM2/4/15
to comman...@googlegroups.com
Thanks for the feedback on the TCP
Client when running as 0.0.0.0, seems I mistook how that was
implemented for client sockets.
The use of loopback systems is something that has been in place for quite a while, and it is very handy to bypass the network stack completely in these cases.
It was implemented this way for Improved efficiency. No point having the substantial burden of TCP sockets involved when we can just direct data instantly internally.
Changing this would impact too many setups and not provide anything beneficial in my opinion.
Support for the IR transmitters on Android devices is not something we will be implementing. Too much fragmentation on the Android platform and there are much better ways of sending IR.
The use of loopback systems is something that has been in place for quite a while, and it is very handy to bypass the network stack completely in these cases.
It was implemented this way for Improved efficiency. No point having the substantial burden of TCP sockets involved when we can just direct data instantly internally.
Changing this would impact too many setups and not provide anything beneficial in my opinion.
Support for the IR transmitters on Android devices is not something we will be implementing. Too much fragmentation on the Android platform and there are much better ways of sending IR.
myrealemai...@gmail.com
Feb 5, 2015, 1:13:55 PM2/5/15
to jar...@commandfusion.com
Hi Jarrod,
You're welcome.
In no way was I suggesting that a TCP stack become involved on loopback implementations. I completely agree that it is not needed for the loopback. Even with the java interface I cited, if you call "getLoopbackAddress" the TCP stack will not be loaded.
In using 127.0.0.1, many call that the loopback address and, in my opinion, that is where the confusion results since 127.0.0.1 is also the localhost address. They are two different things going by the same name, and unfortunately, they do not necessarily smell as sweet. ;) As a for instance, samba on linux requires 127.0.0.1 to have a TCP stack, otherwise, it will not work properly on the host machine.
What I was suggesting is to allow users to specify localhost connections that include a TCP stack (without having a dependency on being attached to a WiFi network) in addition to the currently implemented loopback systems and leave the TCP stack out of the loopback system just like it is currently implemented since there is no need to change anything there.
Thanks again.
You're welcome.
In no way was I suggesting that a TCP stack become involved on loopback implementations. I completely agree that it is not needed for the loopback. Even with the java interface I cited, if you call "getLoopbackAddress" the TCP stack will not be loaded.
In using 127.0.0.1, many call that the loopback address and, in my opinion, that is where the confusion results since 127.0.0.1 is also the localhost address. They are two different things going by the same name, and unfortunately, they do not necessarily smell as sweet. ;) As a for instance, samba on linux requires 127.0.0.1 to have a TCP stack, otherwise, it will not work properly on the host machine.
What I was suggesting is to allow users to specify localhost connections that include a TCP stack (without having a dependency on being attached to a WiFi network) in addition to the currently implemented loopback systems and leave the TCP stack out of the loopback system just like it is currently implemented since there is no need to change anything there.
Thanks again.
myrealemai...@gmail.com
Feb 5, 2015, 2:03:42 PM2/5/15
to comman...@googlegroups.com
Just a quick follow-up with the page from wikipedia on localhost/loopback. It does, perhaps, a better job of explaining localhost / loopback than I did.
Jarrod Bell
Feb 5, 2015, 9:36:23 PM2/5/15
to comman...@googlegroups.com
You could try entering "localhost"
rather than "127.0.0.1". This might bypass our loopback system
functionality and actually communicate with the network stack -
not entirely sure on this however.
If that is the case, then that is a solution for you.
If that is the case, then that is a solution for you.
On 2/6/2015 5:13 AM, myrealemai...@gmail.com wrote:
Hi Jarrod,
You're welcome.
In no way was I suggesting that a TCP stack become involved on loopback implementations. I completely agree that it is not needed for the loopback. Even with the java interface I cited, if you call "getLoopbackAddress" the TCP stack will not be loaded.
In using 127.0.0.1, many call that the loopback address and, in my opinion, that is where the confusion results since 127.0.0.1 is also the localhost address. They are two different things going by the same name, and unfortunately, they do not necessarily smell as sweet. ;)
What I was suggesting is to allow users to specify localhost connections that include a TCP stack in addition to the currently implemented loopback systems and leave the TCP stack out of the loopback system just like it is currently implemented since there is no need to change anything there.
Thanks again.
On Wednesday, February 4, 2015 at 9:49:40 PM UTC-5, Jarrod Bell wrote:Thanks for the feedback on the TCP Client when running as 0.0.0.0, seems I mistook how that was implemented for client sockets.
The use of loopback systems is something that has been in place for quite a while, and it is very handy to bypass the network stack completely in these cases.
It was implemented this way for Improved efficiency. No point having the substantial burden of TCP sockets involved when we can just direct data instantly internally.
Changing this would impact too many setups and not provide anything beneficial in my opinion.
Support for the IR transmitters on Android devices is not something we will be implementing. Too much fragmentation on the Android platform and there are much better ways of sending IR.
myrealemai...@gmail.com
Feb 6, 2015, 12:37:02 PM2/6/15
to comman...@googlegroups.com, jar...@commandfusion.com
Hi Jarrod,
Thanks again for your reply and your patience with a customer doing the very uncommon thing. :)
I tried that. In the hosts file on the device, localhost is specified as 127.0.0.1 - as it should be; however, iViewer treats this as the loopback interface and it acts the same as if I had put in 127.0.0.1. My guess is that iViewer always treats 127.0.0.1 strictly as the loopback interface no matter how it gets that address since it is must be doing a name lookup when localhost is used.
Right now, I do have a solution with that involves a separate app. If iViewer were to allow a means of specifying that a user really wants localhost (not getting rid of the loopback interface, of course), my solution would not need the separate app, and that would be, to me anyway, the ideal case.
With the separate app solution, there is enough functionality in iViewer and that the separate app has available to it (basically anything supported by Android) that I can automate the switch between the app and iViewer. Though I have not tried it yet, I know that I can listen for network / connection state changes in the app and then when the app detects that the WiFi network has connected, I can launch iViewer (I presently have a button in my separate app that launches iViewer). I also changed my service to allow multiple clients to connect to it as I have iViewer configured to hold onto the connection. Lastly, there is enough functionality in iViewer such that I can trigger iViewer, when shutting down the system, to send a message to the service to launch the "System On" app.
A quick question on that note: is iViewer able to launch a user-specified app that is installed on the device?
Right now, I have what I need and it does seem to be working well enough to be usable; however, it would be a cleaner solution if localhost were also available in iViewer.
Thanks again.
Best Regards,
Matthew
Thanks again for your reply and your patience with a customer doing the very uncommon thing. :)
I tried that. In the hosts file on the device, localhost is specified as 127.0.0.1 - as it should be; however, iViewer treats this as the loopback interface and it acts the same as if I had put in 127.0.0.1. My guess is that iViewer always treats 127.0.0.1 strictly as the loopback interface no matter how it gets that address since it is must be doing a name lookup when localhost is used.
Right now, I do have a solution with that involves a separate app. If iViewer were to allow a means of specifying that a user really wants localhost (not getting rid of the loopback interface, of course), my solution would not need the separate app, and that would be, to me anyway, the ideal case.
With the separate app solution, there is enough functionality in iViewer and that the separate app has available to it (basically anything supported by Android) that I can automate the switch between the app and iViewer. Though I have not tried it yet, I know that I can listen for network / connection state changes in the app and then when the app detects that the WiFi network has connected, I can launch iViewer (I presently have a button in my separate app that launches iViewer). I also changed my service to allow multiple clients to connect to it as I have iViewer configured to hold onto the connection. Lastly, there is enough functionality in iViewer such that I can trigger iViewer, when shutting down the system, to send a message to the service to launch the "System On" app.
A quick question on that note: is iViewer able to launch a user-specified app that is installed on the device?
Right now, I have what I need and it does seem to be working well enough to be usable; however, it would be a cleaner solution if localhost were also available in iViewer.
Thanks again.
Best Regards,
Matthew
Vladimir Shabunin
Feb 6, 2015, 2:00:12 PM2/6/15
to comman...@googlegroups.com
Hi Matthew.
You may add Web page component and assign his serial join to localhost:55000/somedata using CF.setJoin. It's not a tcp client and you can't get feedback from your system but at least you can send Get request to your service. You can try also CF.request to localhost but I'm not sure about it.
You may add Web page component and assign his serial join to localhost:55000/somedata using CF.setJoin. It's not a tcp client and you can't get feedback from your system but at least you can send Get request to your service. You can try also CF.request to localhost but I'm not sure about it.
Jarrod Bell
Feb 6, 2015, 9:47:41 PM2/6/15
to comman...@googlegroups.com
We will look at adding an option to
"disable network bypass" for loopback systems in future. This
would be the best way forward, so that existing systems would not
be affected at all.
iViewer can launch other apps on iOS via URL schemes. I believe the same is possible on Android, but might not be implemented in the current public release. I will get back to you on this one.
iViewer can launch other apps on iOS via URL schemes. I believe the same is possible on Android, but might not be implemented in the current public release. I will get back to you on this one.
myrealemai...@gmail.com
Feb 9, 2015, 1:36:03 PM2/9/15
to comman...@googlegroups.com
Hi Vladimir,
Thanks for your reply.
I've been wondering about doing this with JS. I'll look into it.
Best Regards,
Matthew
Thanks for your reply.
I've been wondering about doing this with JS. I'll look into it.
Best Regards,
Matthew
myrealemai...@gmail.com
Feb 9, 2015, 1:37:17 PM2/9/15
to comman...@googlegroups.com, jar...@commandfusion.com
Hi Jarrod,
Thanks for considering this. I agree that the best way would be to leave loopback the default so as to not break existing systems.
I will appreciate hearing if iViewer can launch apps on Android.
I have most of what I am doing in a reasonably working state. I put in a listener in my "Home Theater Startup" app that launches iViewer when the WiFi connection is established. Since iViewer is dependent on the WiFi connection in general (not just for talking to my service), it seemed to make sense to do it this way.
Best Regards,
Matthew
Thanks for considering this. I agree that the best way would be to leave loopback the default so as to not break existing systems.
I will appreciate hearing if iViewer can launch apps on Android.
I have most of what I am doing in a reasonably working state. I put in a listener in my "Home Theater Startup" app that launches iViewer when the WiFi connection is established. Since iViewer is dependent on the WiFi connection in general (not just for talking to my service), it seemed to make sense to do it this way.
Best Regards,
Matthew
Jarrod Bell
Feb 9, 2015, 3:54:00 PM2/9/15
to comman...@googlegroups.com
Details for launching other apps on
Android are now available in the freshly updated JS docs:
http://commandfusion.com/docs/scripting/util.html#cF.launch
http://commandfusion.com/docs/scripting/util.html#cF.launch
myrealemai...@gmail.com
Feb 10, 2015, 3:18:39 PM2/10/15
to comman...@googlegroups.com, jar...@commandfusion.com
Thanks, Jarrod!
Reply all
Reply to author
Forward
0 new messages