RSend Project - Free Windows Instant Messenger for LAN and WAN
RSend is free software for instant messaging in Microsoft Windows Network
RSend is designed for enterprises with a distributed network of branches in different subnets and connected through slow links. RSend is easy to use, doesn't require installation and maintenance of administrator, provides integration with Active Directory, deployment via group policy.
RSend key features
Video (HD) with demonstration of RSend in a real production environment (!) you can see by clicking on the link
youtube.com/watch?v=PF8n5tZgEkM
Screenshots
Why there was a project RSend
Many companies have been used software for instant messaging for years and our
company was no exception. Most often this software was used by IT professionals
and other staff, who understood the convenience of the instant messaging. In previous
years we used a messenger built in OS Novell Netware, but after migration to Microsoft
Windows it was changed by Net Send. However, due limitations with subnets (more than
half of our computers outside main office and are connected via VPN channels) we
could not send messages to computers behind routers. There was no sense to use Net Send
any more. The situation worsened after the appearance of Windows Vista, in which the utility
Net Send has been excluded for security reason. There have been some attempts to use
other products for instant messaging. Unfortunately,
for some reason, they do not quite meet our needs. The main one is ability to work with a
large number of computers on subnets.
In a more detailed study of the issue has come understanding that a possible solution is to
use a product with "client-server" architecture. The eye was turned to the various programs
for chat. On the one hand, they could solve the issue of exchange messages with subnets;
on the other hand there was a question about extra traffic on VPN channels in standby mode
so far as chat assumes frequent clients connections to the server for verification of incoming
messages. You can reduce the amount of unnecessary traffic by increasing the timeout between
the clients requests to the server, but this in turn will lead to delays in message delivery.
Instant messaging is helper software in a production environment, and give it the traffic on VPN
channels would be wrong. It was therefore decided to implement a new product that meets the
following requirements (see left).
To implement client-server architecture of the project was chosen Visual C# and .NET Remoting
technology that has proved itself as reliable architecture for many years.
In most cases with .NET Remoting is used the classic scenario: a client initiates a connection to the
server over TCP (or HTTP) channel, registers and then periodically calls a function on it to
send/receive data he is needed. This approach solves most of the requirements identified in the task,
except for two things: fast message delivery and minimizing traffic.
Client ---------------> Server
To implement these two requirements the classical scenario has been changed as follows: the client initiates a connection to the server via TCP channel, registers and enters standby mode (listening). When the server receives messages from the client, the server according to a list of recipients initiate a connection back to these clients and calls the appropriate function on the remote client (server and client are reversed).
Client --------------> Server Client <-------------- Server
As a result, there is no need for frequent access of the client to the server for verification
of incoming messages and, consequently, a traffic decrease in standby mode. The client
contacts the server only to confirm its presence in the network. Frequency of confirmation is
controlled by a timeout parameter in the configuration file. For example, during a timeout of 90
seconds the daily traffic between the client and the server is less than 150 Kb. To provide fast
delivery of messages to large group of recipients the server engine has been implemented to work in asynchronous
multi-threaded mode on a competitive basis. The first tests showed a very good performance.
For example, 6 testers simultaneously sent messages to 400 recipients. Total delivery time is
about of 2-3 seconds (file server HP G5 with Windows 2003 R2 is used for testing purposes).
* In 2015 the company had already more than 900 employees, but the performance of RSend remained at the same level.
The developed algorithm was fully matched to the task. It remained to implement the user
interface and come up with the name of the program. After a brief hesitation the program was
called RSend (Remoting Send) in honor of .NET Remoting technology.
A few new ideas were born during the development of the user interface: private groups,
built-in filter and search, hotkeys, online help, multi-language interface and other. RSend
deployment in production environments was performed by using group policies, and since
September, 2012 RSend is successfully operated.
For more information about RSend please refer to
Administrator Guide and
User Guide.
Sincerely, Ihar Hrunt
MCSD App Builder
MCSA Windows Server 2012
P.S. I want to thank Vladimir for the idea of developing RSend
and Vasilets Sergey whose advices helped to make RSend interface user-friendly.
