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            

  • MS Windows XP/V/7/8/10/2003-2012;
  • Client-server architecture based on .Net Remoting technology and C#;
  • LAN / WAN messaging implementation;
  • Min consumption of channels bandwidth and computers resources;
  • High productivity and performance;
  • Fast messaging to large groups of users;
  • Number of users up to 1,000;
  • User and computer names as recipients;
  • Usage of AD groups (users, computers, mixed, nested, shadow) as recipients;
  • Ability to create own private groups;
  • Max message size is up to 1,000 chars;
  • Buit-in filter and search engine;
  • User-friendly interface, multi-language support, online help, hot keys;
  • Availability of command-line utility;

  • Video (HD) with demonstration of RSend in a real production environment (!) you can see by clicking on the link


    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.