Is it possible to run two processes on the raspberry pi simultaneously?
I would like to start a MQTT server AND run Home Automation webserver (Home-Automation.io) at the same time.
Thanks,
A raspberry pi is just like any other Linux computer, it will happily run many processes at the same time.
The only possibly problem would be if 2 processes wanted to use the same network port as a server. Since Home-Automation.io does not appear to run it's own MQTT broker (but it is capable of subscribing to topics published on a broker) there should be no problem running it at the same time.
Related
The broadcast stops working 5 seconds after the start. All ports are open. Why can this error still occur?
If you run Ant Media Server on Ubuntu virtual machine on Windows host and run browser (as WebRTC peer) on host (Windows) side, then you can encounter with such a problem.
As a solution, you can start browser on virtual machine side. Or better run AMS on a real machine or VPS.
What is the proper way to connect an app to a device? At the moment, I have a raspberry pi 3 that controls something about electricity and an iPhone app I created. Every time the app goes to foreground, it sends a UDP broadcast message, when the app receives a response from the raspberry pi, it uses that IP address (in the IP header) to consume the web services I created in the hub. This UDP process is done all the time you run the app. Is this what IOT devices usually do? I assume the raspberry pi IP will change sooner or later.
A colleague of mine told me another way: After the first time I get the IP address, instead of using UDP broadcast messages every time the app runs, use ICMP to ping the previously saved IP address to see if it is responding. In that case, I use the web services with that IP address, otherwise, use the UPD broadcast message again.
I don't see the point of that. Basically because the system is not faster using ICMP. (a UDP request is more or less as fast as an ICMP request). Moreover, maybe, another device started using that IP address now (like a smart TV or a smart plug) and for that reason, it is not going to reply to the network requests sent by the app. In that case, the app cannot recover, because it thinks it is already connected to the proper device. As far as I understand, ICMP is a protocol use for diagnosis, not for devices discovery.
What do you think? What's the process used by devices like Alexa, Philips Hue, Smart plugs... to solve the problem of discovering the devices by their apps?
It seems Philips HUE is using SSDP, which under the hood uses a UDP broadcast message. Is it used every time you run the app to discover the IP address? (I am going to check this later with wireshark)
Thanks for suggestions.
You can enable the hostname of your Raspberry Pi to be accessible on your local network through:
http://raspberrypi.local
To enable it, you need to install Bonjour support on your Raspberry Pi by installing the Avahi mDNS daemon (implements Apple's Zeroconf architecture):
$ sudo apt-get install avahi-daemon
Update boot startup:
$ sudo insserv avahi-daemon
Restart to apply the new configuration:
$ sudo /etc/init.d/avahi-daemon restart
I have been trying to get Raknet up and running on my Raspberry Pi (2).
I am using a simple client server test program to connect from my windows machine to my raspberry pi. Using tshark on the Pi I can see that all message are arriving on the Pi. However, the server application does not seem to pick those up. As far as I can deduce all ports are open, the machines are on the same network, the code is correct (taken from some github repo with examples for raknet).
The frustrating thing is that a while back I though I solved this communication by starting my server app as root (sudo). However, in the meantime something has been changed in my setup which makes this no longer the case. Any help is appreciated.
I completely forgot about my question here. It actually had to do with privileges on the networks we use here. I had been testing on two different networks without realizing. Problem has been solved.
I've being doing a installation process in several machines in virtualbox and I'd like to try automated this process. I can do a expect script (see below), however I can't connect through ssh because this script will configure the network stuff after some other processes.
Where I work now, we use the vmware esxi and I am trying to discover if it's possible to automated the installation process that I said if I setup the vnc viewer in the guest machine. I can do the all process if I do it manually, but I'd like try to automated it. Although I think a expect script will be fine, I'm not connecting by ssh. Is it possible?? I started to think that maybe expect is not my answer here.
The processes is something like this:
Receives "Choose a option: ", sends "1\n"
Receives "Press any key", sends "\n"
Repeat step 2 more two times.
Receives "Do you agree (y/n)?", sends "y\n"
And so on.
The host as I said is a vmware esxi, the guest is similar to a linux and my machine is a fedora 20 (I'm saying this because I dont like the idea of install stuff on esxi).
Can someone explain what is the difference between X server and Remote Terminal servers in simple terms?
For example, Hummingbird Exceed is an X server and Citrix is a Remote Terminal Server. How do these servers work?
A terminal server runs at the "other" machine while you use a remote desktop client to view the other machine's screen.
A X server (of the X11 Window System) runs on your machine while another machine (or several thereof) send their output to your computer.
The most important difference to the end user is probably "culture": With the X Window system you typically work with windows that run on several hosts. (You often sit in front of a quite stripped down workstation, get one application from one computer, another one from another computer.) When working with X things feel very heterogeneous - a special application only runs on a HP workstation while your company is stuffed with suns or linux boxes? No problem, just buy one HP, everone can use that application over the network like as it was local.)
Remote terminal services feel more like another computer sends its complete screen to you, more like you have a 100-Mile-Long monitor and usb cable (with a little lag built in). You typically use a remote desktop client that sends a complete desktop to you.
However in recent times both techniques get close to another - windows remote desktop (which is based on citrix) can send only application windows to your desktop, while a lot of programs based on X11 are theoretically network transparent but practically need to run on the local machine. (Sorry, no 3D shooter over the network - an extreme example).
Which one is better? I don't dare to say. White X11 is a lot more flexible (it was designed with network transparency in mind - it makes absolutely no difference if an application runs local or remote - it is in many aspects more complicated. As long as there was no remote desktop sharing there was a clear advantage, but slowly the gap is closing, for example by terminal services now allowing you to do many things that were available with X11 only in earlier times.)
By the way, the main reason many X11 application still feel a little "snappier" over the network than windows counterparts is the thing that many application programmers on windows still think they always run local and dump a lot of bitmap graphics on the screen - like custom toolbars in ZIP tools. X11 applications did not do this for a long time and chose "ugly but fast" because X11 forces you to think about the network. But as X11 applications get more pretty and Windows programmers more aware about terminal services the difference will dwindle.
Oh and an important point: X11 is deeply ingrained in the Unix way of things, Citrix is mainly used on Windows (in the form of Microsoft's Windows Terminal Services - which originated in Citrix code). So lock a terminal services admin and a X11 operator into a cage and step back watching bloodshed when they figure out who they are locked in with ...
An X server most likely refers to the X11 windowing system, which is the GUI that most unix flavors (including linux) use. It's a client/server setup, and has been around for a very long time
A remote Terminal Server in the case of Citrix is a remote windows instance that can be connected to with a special Citrix client. The Citrix environments I'm familiar with are all MS Windows solutions, ie they work similar to X, but are for Windows Servers only
They both sort of operate in similar fashions, which is serving a remote client a windowing solution. IE, they both let a server run the actual application while the display of that application is sent back over the network to a client PC.
A 'Terminal Server', as it's called, basically allow you to connect to a Windows session remotely. They employ a bit of magic to make the experience snappy over connections with latency. The Windows GUI system isn't network transparent like X, so it took a while longer to get this feature. Windows Server 2008 and Citrix products have the ability to let you use a single application, unlike the traditional Terminal Server.
X is the GUI protocol for Unix/Linux. The X server accepts connections and displays their windows. The clients are actually the programs themselves. These clients can be local or remote, it doesn't matter to X. X just displays them as requested, on the local screen or over a TCP connection. This is lower level stuff than terminal servers, and allows graphical programs to run on one machine and display on another. X11 doesn't compress or encrypt the traffic like RDP does (although SSH can help you out there).
The linux equivalent of RDP is NX. They provide free software to run NX servers/clients. I've used it and it works pretty well.