Alternative network messaging?

Hello people,
which options do I have to send messages over a network from one station to another without using standard network messaging commands like write, talk und message? Thanks.

I suppose it depends on what you call sending a message. email works for most of us. You can ssh between hosts, but to message people youu need to find specific tty names as well. If you want them to reply, you need some sort of artifact there for them to send through. I once tried something with mmap() atached NFS files, but changes were not picked up unless I did an ls on the end remote from the write. Maybe if everyone tailed a file and wrote to that file under an id header line in tight blocks, you would have a logged chat session. I have done that. If you have no NFS, you can "ssh ... tail -f chatfile &" to see the dialog on one xterm and do an ssh to write blocks from another. You write blocks by composing them in an env variable and then echoing the variable as one atomic write. Oh, I said that word, but the command is echo not write.

Thanks. Well, I thought of a primitive SMS-like messaging function that allows to send messages either to one user or to a group of users. I thought I could use nc for that task, but I don't know if it's a good option.

What would would you recommend to simulate a network? Is it better to use multiple IP aliases on one physical host or to use multiple VMs?

If you want it to be utterly open, you might write something using UDP on a fixed high port and broadcast messages. It works to run at least one big name stock exchange. I suppose you might want some authentication so you know who you are talking to, and that means a server daemon or some peer equivalent.

I think I am going to simulate a network with VirtualBox, because here I have arbitrary amount of independent OSs.

The shell script should work like this:

1. The user logs in. Depending on his privileges, he can send messages to one user or to a group of users.
2. The receiver gets the message. If he is not online, the sender gets an error message.
   The whole script shouldn't be based on P2P.

I am still unsure on which core commands this script should be build.

Some sort of JAVA or PERL app would be very portable and consistent across O/S.

I'm not allowed to use any other language than Linux Shell Script. In my opinion, rcp or nc are the only commands that could be used for network messaging.

Well, scripts and commands they can call, apparently.

One paradigm that might work for you is to have users drop comments as files in a dir, and have a daemon gor around polling all the comments and moving them to a common message file that is then extended on every host, where viewers are watching it with tail -f. More ssh/rsh than whatever.

A messaging milieu needs authentication, a directory service of discussions one can join, a means of viewing the discussion and a means of appending commetns to the discussion. You might extend it to having admins and chairpersons for better control. If discussions are long, each user should have a high water mark setting in every discussion so they can catch up. A facility for attachments like email is nice, too. Then there are things like abuse reporting, blocking, encrytption of records. It pays to envision with a very open mind.

This script can be much easier: Just a message should appear on the receiver's terminal. Depending on the user privileges, the message can be sent to only one or to all users. A simple chat is possible with netcat, but it has to be instantiated from both sides. Maybe it could be better done with rcp, but here some kind of event listener would be necessary.

Writing to the tty of another user usually has permission problems. If you have one window for the discussion, which is "tail -f mtg_file" and one for comments 'while read l ;do echo `id -un`": $l" >>mtg_file ;done' then all you have to worry about is file permissions and ssh if remote. You might what to use an xterm with a big scroll buffer and not set to return to the bottom on every output. Or you chould share a google drive doc.

Maybe my approach isn't optimal, but my shell scripting knowledge is only a couple of days old. I thought it could work like this:

Dispatcher:
Writes text into a file. The file is sent to the receiver by rcp command.

Receiver:
A process is running in the background that is waiting for incoming messages. When a message is detected, it's written on the console. The messages are stored in /tmp/var or /tmp.

Oddly enough, that approach sounds a lot like how an email originated. It could work. Polling is never efficient but if more sensible method are denied you nothing better pops to mind.

Do I have any better options in shell script than polling (while-sleep-construct)?

Polling is an architectural choice. If the originators have a subscription list or a common destination, they can push. Polling is about pulling information that may not exist yet. Then there are signals, which shells can send with kill and receive with trap. Two signals are reserved for app use. Signals allow for interrupt driven processing, which is a sort of push, in that the originator pushes a signal. The master can process signals one at a time so no chaos erupts. However, the signal is pretty bare, does not tell you who is calling, so you need a per sender message file, even as just a flag, that is only polled on interrupt. That's nicer than polling in a tight loop wasting and destroying resources, or sleeping and ignoring new data. There is often a little poll under an interrupt. You could have the message files be queued in a special directory, named uniquely, so on interrupt the master processes each and then deletes it. The file name or content may just tell the master where to go for the full message, or may be the full message. Files can be composed elsewhere on that file system or in that dir but with a filtering extension, and mv'd when complete, so there is no race condition. Directories provide all the necessary locking and list management for multiple simultaneous writers. Exploit them.

I would like to implement a push service, but I havent't found any example for that on the internet yet. The step from "kill" command to push service is too large for me.

A signal is a way to tell a program to do something when told instead of constantly checking for something. If it hasn't been told to do anything when it gets the signal, the signal will probably kill it instead.

#!/bin/sh

# Display the contents of a file and set a variable on SIGINT
trap 'cat /tmp/filename ; rm /tmp/filename ; VAR=1' INT

echo "My PID is $$"

while true
do
        VAR=0
        # Two reason read might fail -- end of file, or SIGINT.
        # If it was interrupted, just try again.  Otherwise, quit.
        if ! read LINE
        then
                [ "$VAR" -eq 1 ] && continue
                break
        fi

        echo "read line from keyboard: $LINE"
done

Run this in one window:

$ ./stupidchat.sh

My pid is 21188

Then do this in another:

# Vitally important message
$ echo "hey guys alj af MY FACE IS A ROTTORN BANANA" >/tmp/filename
$ kill -INT 21188

...and the first script should receive the signal, trap it, read the file and delete it

Thanks for your example
There is still a problem, because I can't call "kill" on a remote machine. Hence, I can only call a remote script that sends the signal to the remote process. Is It better to call the process by name or by process ID? Will the process ID be constant after reboot?

Yes, kill is named for it's most popular use, termination, but it is just a signal sender.

in shell, trap is the shell signal catcher. SIGINT was available, but for apps SIGUSR1 and SIGUSR2 are most appropriate: Man Page for signal (linux Section 7) - The UNIX and Linux Forums

The signal processing is done out of sequence with the process thread(s), but in the same process so variables are passed.

So, you can push files to input-dir/unique.take-me-extension, the final step being mv and then kill to start the possibly, usually sleeping server so it processes the input.(

ssh server_host 'cat >input-dir/unique.take-me-extension.tmp
  mv input-dir/unique.take-me-extension.tmp input-dir/unique.take-me-extension
  kill -SIGUSR1 `< server-pid-file`
 ' < input-file

Of course, you have to be the same id or root to signal a process. Named pipes can stall servers that only require the writer have permission on the pipe.

$ mknod p p
$ ls -lA|grep '^p'
prw-r--r--   1 my_uid    my_group          0 Oct 25 14:54 p
$ while :
do
 cat <p
done &
[1]     19299
$ echo hi >p
$ hi
echo hello >p
$ hello

There may be a hundred scripts running with the same name, but they will all have different process ID's.

No. The usual procedure is for a process to save a file under /var/run/ somewhere containing its process ID for other things to check.

The whole app shall be some kind of LAN messaging program with a central host that receives, stores and forwards messages to the correct receiver when he is online. For sending messages over the LAN, rcp shall be used.

On the mediator host, each user has a folder where all the messages are stored that are addressed to him. Therefore, each sender must be able to send a signal to this mediator host when a message has been sent. I haven't yet completely understood how to call unambiguously a process on this host.