Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28442

Re: "Device-to-smartphone" and "smartphone-to-device" technologies

Show all headers | View raw

Il 11/12/2018 15:50, Dimiter_Popoff ha scritto:
> On 12/11/2018 15:27, pozz wrote:
>> Il 10/12/2018 21:50, Dimiter_Popoff ha scritto:
>>> On 12/10/2018 15:51, pozz wrote:
>>>> Il 10/12/2018 13:09, Dimiter_Popoff ha scritto:
>>>>> On 10.12.2018 г. 12:33, pozz wrote:
>>>>>> Il 10/12/2018 11:04, Dimiter_Popoff ha scritto:
>>>>>>> CPU power is abundant nowadays, so is connectivity. Just make your
>>>>>>> device look like say an RFB (aka VNC) server and use the smartphone/
>>>>>>> tablet/PC simply as a terminal.
>>>>>>
>>>>>> When the device *is* a server, you need at least Dynamic DNS and port
>>>>>> forwarding. Too bad for many users.
>>>>>>
>>>>>>> We have been doing that for over a decade on our netMCA devices,
>>>>>>> long before the "IOT" word had been coined I think.
>>>>>>
>>>>>
>>>>> If being a server is a problem make the device a client.
>>>>> realVNC can be started in "listening" mode, so the device
>>>>> connects to it, it can do that from behind a NAT router without
>>>>> a problem.
>>>>> This is how our netMCA series has been providing online
>>>>> customer support for over a decade now.
>>>>
>>>> I'm not sure I got your point.
>>>>
>>>> Where does realVNC run in "listening mode"? On a smartphone?
>>>
>>> The android version cannot do that indeed.
>>>
>>> So write your own viewer, RFB is simple enough, this is a huge
>>> advantage.
>>> Anything else you contemplate would take a lot more work for
>>> android or whatever.
>>
>> You insist suggesting a point-to-point (device-to-smartphone) 
>> solution. I don't think this can be done.
>>
>> For notifications, the device could alert the smartphone at any time, 
>> when the user is working at PC or playing tennis. In this case, the 
>> smartphone OS is sleeping, so all the services/apps aren't using 
>> Internet (all connections are closed). How the device could reach the 
>> smartphone/viewer?
> 
> So how does the device reach anything you contemplate running on a
> phone which is off. You seem to keep on trying to find a solution
> to your quest "how do I have a DNS capable server without having one".
> The answer to that is obvious enough I hope.

I usually don't power off my smartphone when working at PC or during a 
tennis mach bettwen hobbyist. The smartphone is in standby and this 
means all apps aren't active, in other words they can't communicate over 
the Internet (at least on iOS).

However there is a mechanism that let to push something to a sleeping 
smartphone, this is "push notifications". It's the same technology that 
creates a notification on your phone when you receive a Whatsapp message.

For what I know, this technlogy is based on a high-priority service 
running at the OS kernel level. It's a process that can always 
communicate over the Internet thanks to a persistent TCP connection.

Google and Apple have service for app developers that let them send 
notifications to one or mode smartphones. Many other services were born 
that let the developer to send notifications in a simpler manner.

I think this is the only way for device-to-smartphone 
alerts/notifications. IMHO here your RFB/VNC doesn't work.


>> Even for generic remote control your solution doesn't work. The user 
>> may want to connect to his home at any time, when the device behind a 
>> router doesn't know. How the smartphone could reach the device?
> 
> Oh it works and has worked for about a decade now. The netMCA keeps on
> attempting to connect to the listening VNC nodes (you can set multiple
> of these) every 20 seconds or so.

I can't see how. RFB is a TCP protocol. This means one is the server and 
one is the client. As we already discussed, the device behind a router 
can't be a server, so it must be a client.

Now, the server should be the smartphone. We can think to update our 
public address on a dynamic DNS service when the user open our app 
(myphone.dyndns.com). The device/client behind the NAT could try to 
connect to myphone.dyndns.com every 20 seconds. The app should be able 
to create a connection with the device in maximum 20 seconds. This could 
be ok in some cases.

However I'm not sure if the mobile operator will forward to your phone 
all the TCP packets, including the ones for TCP connection 
establishment. Are you sure the mobile operator assigns to your phone a 
*public* IP address, even if dynamic. In the latter case, you would need 
port forwarding on mobile network... much more difficult than port 
forwarding in my home.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

"Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-09 23:49 +0100
  Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 12:04 +0200
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 11:33 +0100
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 14:09 +0200
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 14:51 +0100
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 22:50 +0200
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 14:27 +0100
              Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-11 16:50 +0200
                Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 23:34 +0100
                Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-12 02:26 +0200
  Re: "Device-to-smartphone" and "smartphone-to-device" technologies Theo <theom+news@chiark.greenend.org.uk> - 2018-12-10 14:34 +0000
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 23:05 +0100
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies Theo <theom+news@chiark.greenend.org.uk> - 2018-12-11 11:58 +0000
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 14:36 +0100
  Re: "Device-to-smartphone" and "smartphone-to-device" technologies lasselangwadtchristensen@gmail.com - 2018-12-10 13:17 -0800
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 23:05 +0100
  Re: "Device-to-smartphone" and "smartphone-to-device" technologies Robert Wessel <robertwessel2@yahoo.com> - 2018-12-10 20:18 -0600
  Re: "Device-to-smartphone" and "smartphone-to-device" technologies Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-12-12 08:34 +0200
    Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-13 13:51 +0100
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-13 10:09 -0800
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 18:59 +0000
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-13 11:17 -0800
            [OT] Gopher Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2018-12-13 21:00 +0100
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 20:37 +0000
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies Clifford Heath <no.spam@please.net> - 2018-12-14 08:12 +1100
            Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 21:46 +0000
        Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-14 09:17 +0100
          Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-14 15:18 +0000
      Re: "Device-to-smartphone" and "smartphone-to-device" technologies Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-12-15 18:20 +0200

csiph-web