Look at ssh. It is simple, well documented, secure. Not sure what else you need. The client initiates an ssh to the server and either writes to a file or scp's over a file. The server has a daemon process watching and acts when the file shows up. Simple.

Heh, is that just an opinion or your practical experience actually having used SNMP? FWIW if you want "easy" then why not use a Netcat listener on the server and let the clients 'echo HELLO | nc server port' and be done with it? OTOH if you already use Xinetd (which you hinted at in one of your earlier posts) then a simple /etc/xinetd.d/ service could do as well. No need for added complexity in terms of libraries, daemons, user accounts and whatever else SSH would require.

Earler you said:
Maybe it's me, but as I get it, this doesn't add up. You've lost me there.
If it does add up, there must be some info missing about what it is exactly that you are trying to do. Or is it that you just want to create something that works over the network? (which can be a good argument imho)

To make it clear, I want to build a rcp/scp-based service, that sends files to remote users. To prevent constant polling, I need some kind of notification service for two possible situations:
1. The dispatcher sends a notification to the server after rcp/scp has returned with exit status 0. This notification starts a script on the server that immediately tries to forward the file to the receiver. If the receiver is not reachable, the server stops processing files and waits for the next external event.
2. The receiver wants to inform the server that he is now reachable and shall try again to forward the files he has stored.

I thought about using either netcat or rsh/ssh. Using rsh/ssh I could just call a remote method with the receiver name as argument.
SNMP would be a better solution, but with just a few weeks of shell programming experience maybe too complicated.

That's exactly why I already said "Then maybe it's time you post your requirements in full" in post #6...


Finally...


Isn't rcp / scp already exiting OK a sign the receiver already is reachable and available? In this situation you already got one channel of communication so why complicate things and add another? Doesn't make sense to me.


This really could be any sender / listener combo ranging from having a simple Xinetd listener and the client doing 'echo -en "READY\n"|nc sender_ip port;' to having snmptrapd listening and the client sending something like 'snmptrap -v2c sender_ip public '' .1.3.6.1.4.1.2789.2005.1 s "READY";'.


You might dislike Rational, RUP, Scrum, Agile, 6 Sigma, Lean or whatever but regardless of the methodology one choses to fsck things up with work with, regardless of the size and scope of a project and regardless if it being done instinctively or formally, there will be a stage at which a rough inventory of must haves / could haves / nice to haves gets converted to functional requirements which in turn get converted into technical requirements.
If it takes you a about a week to post "I want to build a rcp/scp-based service" then with all due respect SNMP being "maybe too complicated" is not the problem.

All messages are sent to a mediator server (that is supposed to be always reachable), that then sends them to the endpoint (that is supposed to be not always reachable), the final receiver. Basically the way most instant messengers work. I'm sorry for my incomplete description.

Thanks for the clarification. Kind of reminds me of the Blackberry "push" method. Since I notice you don't have any questions left I'll sign off and wish you good luck with your project.