By UNIX domain socket?
By normal TCP/UDP socket?
In my xenomai layer, I have use xddp to generate one virtual port(/dev/rtp0), normal Linux process can access by open this port, and read/write the stream. But it seams difficult for Qt to access the port using QFile.
By UNIX domain socket?
By normal TCP/UDP socket?
the answer is: yes, both, why not?
Qt processes are normal processes, and they can do whatever other linux processes can do. You should be able to open a device file like you'd open it in any other process. Also note that no-one's forcing you to use QFile; you can use normal fopen/fread/mmap/ioctl.. whatever you do to interact with your /dev/rtp0, but I don't think there's anything stopping you from handling files as QFile and getting the low-level file descripter as soon as you need it from that class.
I tested the QLocalServer, it works! The Qt process can send data to the xenomai process by the UNIX domain socket.
Related
Just a few days after we decided to travel, I thought I has to monitor the house somehow while we are away. So, I need to connect a microcontroller to the appliances and control it through web interface to turn them on or off, and what I'm trying to do is turning my home PC into a server and I've already installed apache and configured it, now to control the microcontroller through the webpage I need to send serial data over the DB9 port. The question is, what is the best way to send serial data from HTML? Is it through javascript or is it something else? And how?
Short Answer:
HTML
Javascript
...and 1 language that has support for TCP sockets and devices (for DB9).
This could be c, c++, python, ruby, c#, Objective-C, Java and so on.
Long Answer:
This system would have 3 components:
The Web Server (HTML/Javascript/CSS)
The RESTful Server (C or Java or Other)
The DB9 Serial Server (Tiny C/Assembly/Other)
The best way to achieve those results is by creating what is called a RESTful API server written in a language that is well integrated into your operating system. You will have to write a program that accepts TCP connections, preferable over port 80 or 443 (for security). The program will then parse http data, headers and body etc, and issue a command to the micro controller accordingly.
Here is a good guide on Rest:
Dr. Dobbs Rest
I'm assuming you know how to send data over a serial line. If your in linux and you have one mounted in the "dev" directory you can just write to the appropriate file. In other situations I've scripted the linux program "screen" before.
You can write your server program in any language that has access to TCP Sockets, which are normally facilitated by sys calls on your operating system.
The RESTful API can be separate from your actual HTML server program...which is apache. Then inside your delivered html content, include a javascript onclick event that will sent a restful request to your restful server.
Is that possible to achieve Inter process communication using any terminal or serial ports in AIX or Unix?
I would like to achieve this by using commands/scripting only where one process writes a string on terminal and another process reads same terminal and processes that string. I know that using pipe also this is possible but I do not have enough idea on that.
Also is there a way we can determine which all ports/terminals are available in AIX machine?
Or is it possible to create new terminal at run time (not the boot time) that will be used by only above two processes?
I think what you want are pty's? Or, another option would be unix domain sockets.
The answer to your first question is "no"... not really. When you write out to a tty, that output is sent out to the real device and not available to be read back.
The list of tty's on a system is: lsdev -Cctty
Creating tty's at run time is possible but not really what you want either. A tty is a child of a serial port and you can not add serial ports arbitrarily. They are real things. With AIX and Power systems, you can add devices while the system is up (hot swap) but that is getting (I'm assuming) way far off your original topic.
The basic different between a pty and a unix domain socket is a pty mimics the output and input process of a real tty in one direction. This is what telnet, rlogin, ssh, and many other daemons use when connections come in. It is easy to make ksh believe that it has a real tty by using pty's. If you don't need that, then they are added trouble that you don't need. Find a link on how to create and use a Unix domain socket and you will have what you need (or a pipe but a pipe requires a parent / child relationship which I assume you do not have).
I need to transfer some ASCII files from one machine to another over telnet. How to send files over telnet?
I know that in minicom etc... you can use zmodem (control a - s), is there a similar thing?
You need a telnet client that can transfer files using zmodem. Not all of them can and certainly the standard telnet client that comes with Windows or Linux doesn't. Off the top of my head I think ZOC (proprietary) supported zmodem.
If you don't HAVE TO use telnet, ssh/scp is a much better option.
How can I do inter-process communication between two remote process on unix C/C++? Currently, popen works for two process on same host? Product need to be capability to call remote process and send /receive the data.
As you mentioned popen you may not realize this already allows you to use ssh to remotely execute a process and treat exactly the same as a locally spawned one.
popen ("ssh user#remotehost /usr/bin/cal", "r")
And a pre-emptive link for further questions on ssh:
https://serverfault.com/questions/117007/ssh-key-questions
why would you nut just open the wild card % in the IP so that they could access the host.. remorely..
192.168.1.% something like that...:D
Im trying to understand the virtual terminal access. I was wondering if anyone know any sources for the Virtual Terminal Access protocol. And other sources like ftp, http, and remote procedure calls.
The RFC Sourcebook...
I'm not sure about the 'Virtual Terminal Access Protocol' though. That's a new one to me. Usually, if you're looking to communicate with a terminal you have to know the model of the specific terminal because there are so many different terminal specifications.
The RFC sourcebook, at the least, will give you a great resource to help implement FTP, HTTP,and RPC.
If you want to see a great example of a virtual terminal check out PuTTY
I suspect you meant the Virtual Terminal Protocol that was part of the ISO protocol stack. It was never widely deployed. The logical Internet equivalent was telnet, which, while extremely useful in its day, was insecure and has since been replaced by ssh.