- Beefing Up the Protocol
- Patching the Holes
- Putting Multicast into Practice
- Improving the Program
- Solving Some Problems
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Improving the Program
At present, the program only accepts messages from one server. The program includes the capability to accept inputs from several sources (multi-sourcing) at different rates and different message sizes. Enabling multi-sourcing significantly reduces server load and maximizes your throughput.
This program is a little promiscuous: It accepts a message from any source. If you enable multi-sourcing, you may have a problem of degraded integrity, because it's difficult to verify the source of the message because of server spoofing/aliasing. The program also assumes that the file is locked and doesn't change while the sender transmits it.
Spoofing (falsified source address) and aliasing (assumed source address) are real problems. Here's a trick you can use to address these problems: Use encryption. The problem with sharing information is that not only does the receiver get the message, but a network sniffer does also. This sniffer can then garble the data and retransmit it. Corrupted messages make the file you get less useful. Using a public environment such as multicasting addresses compounds the problem.
Here's a clever little technique that you can use when sending to multiple designations: Use public-key encryption. Public-key encryption has two keys: a public key for encryption and a private key for decryption. Normally, clients and servers use this process to establish a trusted connection (see my later article on secure sockets).
Before the client and server establish the trusted connection, they give each other their public keys. Using the public key, they encrypt a message that only the receiver can decrypt. This is very powerful and useful on the Internet, because it's very difficult to crack these encrypted messages, and it implicitly authenticates (verifies the authenticity of) the sender to the receiver.
In this multicasting program, you can get secure messaging by turning around the encryption process. Instead of handing out the encryption key, hand out the decryption key. The multicasting server makes the decryption key available, because everyone should be able to read the data. But because nobody but the authenticated sender should generate the data, the server withholds the encryption key.
Using a reversed public-key protocol, the receiving program gets the public key from the server and begins receiving the data. It decrypts the data using the key and stores the file as expected. Because encryption has its own built-in checksums, the program no longer needs to supply a checksum and message digest. In this process, the multicast server encrypts each message, and each receiver accepts the message and crypts it with the published decryption key. This flow is limited only by the performance of the hosts and the network itself. The last limit, network bottlenecks, can restrict the flow of data, however. This can be a particular problem with multicasting; multicast servers need to adapt as necessary.
Not everyone has a T3 or even a 1 Mbps connection, so setting the throughput too high may drown many modem-connected receivers. The network, when hitting this data logjam, may simply drop the incoming messages. This is worsened with a problem between multicasting and ports, described in the first part of this series. When a program subscribes to a multicast address, the network doesn't search for only those packets that match address and port. Instead, all messages matching the address arrive at the receiving computer—regardless of the selected port value. Unfortunately, there is currently no solution for this problem. As the code writer, you must be aware that your users may face this problem, and you may have to adjust programs accordingly.