Thursday, March 22, 2018

Singleton Pattern vs. C# Static Class

I ran into an old foe the other day when we were discussing interview questions; which to choose: standard singleton pattern or static class? At the most basic level, both constructs are useful in limiting the number of instances of an object that can be created. There are numerous subtle differences at the implementation level, but the single biggest difference is at an object-oriented level: static classes do not support polymorphism. This stems from a combination of factors at the language level; in short, a static class cannot inherit from a base class (abstract or concrete) nor can it implement any interface methods. Conversely, you can neither define static virtual methods on a class, nor can you define them on an interface. So, if you're ever using dependency injection - a technique that relies heavily on polymorphism - you will likely find that static classes will be inadequate. There are a number of other runtime level differences, but these are all secondary to the polymorphism issue. The simplest is that a static class can never be instantiated, and all methods are executed against the type instance. Contrast this with the singleton, of which exactly one instance is created, and where methods are executed against that instance. Next time I choose, I'm going anti-static for all but the simplest "utility" classes.

Monday, January 22, 2018

Cisco 7960 SIP Phone

I bought a Cisco 7960 IP phone (preloaded with SIP firmware) to connect with my experimental asterisk server running on a Raspberry Pi. Setting it up wasn't that hard, once I stopped following the bad advice that abounded on Google search results. I'm partially documenting my own experience here - not to help, but to hinder. You don't need a TFTP server (and therefore you don't need to set any hard-to-reach DHCP options) to distribute configuration files, you can do everything you need through the phone's keypad. If you're going to make changes, you need to perform the "Unlock Configuration" steps each time.

Unlock the Configuration

  1. Press Settings
  2. Scroll down to 9: Unlock
  3. Enter the password "cisco"

Set the TFTP server IP address manually

  1. Press Settings
  2. Scroll down to 3: Network Configuration
  3. Scroll down to TFTP Server
  4. Press Edit
  5. Enter the IP address of the TFTP server

Configure SIP on the Phone

  1. Press Settings
  2. Scroll down to SIP Configuration
  3. Select the line you want to edit
  4. Confirm the following entries exist (or add them) [They should match what you've got setup in sip.config on the Asterisk server).

Setup SIP on the Asterisk Server

  1. Add a new block to sip.conf. Make sure the extension and secret match the values you provided when configuring SIP on the phone. [1234] context=home secret=secret etc.
  2. Add a dialplan rule or two to extensions.conf. Make sure the context in sip.conf matches the section name in extensions.conf. exten => 1234,1,Dial(SIP/1234)
  3. asterisk -r then sip reload and dialplan reload

Friday, October 20, 2017

ADSL2+ Sync Rate

If you have ever called up your ISP support team to complain, you may have heard them quote a number called SNR to describe the quality of your connection.

It's not quite as simple as a single number, though.

ADSL2+ uses multiple "channels" at once to transfer data between the ISP and your home modem. In the case of my ASUS modem, there are 512 channels: there is 2.208 MHz of available spectrum on the copper wire; these are split into equally spaced 4.3125 kHz wide channels.

However, not every channel (or bin) is created equally: there is almost certainly some electrical "noise" or congestion on the cables. Some bins are reserved for normal telephone connections, others for upstream and downstream communication with the server, with a few reserved as guards to keep sections separated.

I pay for a 4 Mb/s connection, so let's assume the ISP allows me 1672 bits' worth of downstream sync rate*. It is up to the modem and ISP to negotiate how to allocate the sync rate across the available bins. My modem surveys the ratio of signal to noise (SNR) across each bin in the downstream set of channels. A rule of thumb is that each bit requires about 3dB of SNR to reliably decode the signal without errors. Bins with higher SNR will therefore have higher bit capacity for bits.

My modem allows me to connect with SSH and look at three files, which are ordinarily used by the administrative web server interface to present me a way to easily change modem settings and view diagnostics:
  • /var/tmp/spectrum-bpc-ds
  • /var/tmp/spectrum-bpc-us
  • /var/tmp/spectrum-snr
Let's do some very simple mathematics with the data in these files that won't be too difficult to follow:

Data taken from the SNR file:
1672 bits to allocate
268 channels into which they must be allocated
10,523.27 dB (the sum of SNR across the available reception channels)

3 dB/bit required to convert received signal without errors

1) 1672 bits * 3 dB/bit = 5016 dB SNR required to decode the signal

2) 10,523.27 dB - 5016 dB = 5507.27 dB unused SNR

3) 5507.27 dB / 268 channels = 20.54951 dB unused SNR per channel

4) Now, we iterate each of the 268 channels in turn. I'll demonstrate with the first channel, where the SNR was 24.21 dB.

a) 24.21 dB - 20.54951 dB = ~3.66 dB to be used for data reception

b) 3.66 dB / 3 dB/bit = ~1.22 bits

c) round 1.22 bits to a whole number: 1

It turns out that this simple algorithm gets us remarkably close to the numbers of bits per channel (BPC) in the other files, which are arrived at by the modem's own algorithms. The difference could even be accounted for by (lack of, or outdated) "bitswap", where bins are periodically re-checked for SNR and reallocated to make the best use of the spectrum as it evolves over time.

* Ignore - for now - that those numbers are not equivalent, they are effectively the same thing quoted for different units of time

Wednesday, August 23, 2017


This article on Ars Technica inspired me to try and setup a VPN, but it seemed to lack a couple of extra steps that were required to run the server on a Raspberry Pi behind a router. The official OpenVPN documentation was helpful but long-winded, and I resorted to a few askubuntu answers in the end.
  1. Certificate names

    client-no-pass doesn't have to be replaced with the client host name, but can be (pretty much) any identifier for the client. The important thing is to sign all certificates with the same CA key.
  2. VPN topology

    The default topology of net30 is perhaps not as easy to comprehend as subnet, and subnet works with Ubuntu, Windows and iPhone clients.
  3. Default gateway

    On the server, I needed to push redirect-gateway, push "route" and consequently push "dhcp-option DNS" so that the client would be able to route to the server's local network, and the tun0 device would be able to do DNS lookups.
  4. Firewall rules

    Besides enabling the forwarding of IPv4 so that the Raspberry Pi acted as a router, I need to add three firewall rules in iptables: one for NAT masquerading, and two for accepting new and related established connections.
  5. DNS setup for clients

    The dhcp-options that were pushed to the client were ignored, which resulted in the client being unable to resolve any DNS names to IP addresses. This was only a problem on Ubuntu clients, but the script /etc/openvpn/update-resolv-conf was provided when I installed openvpn; all I had to do was reference it from client-name.config as a pair of lines:
    up /etc/openvpn/update-resolv-conf
    down /etc/openvpn/update-resolv-conf

Sunday, August 13, 2017


It's nice when the Grub bootloader remembers your last choice and reuses it as the default value next time your machine boots. Using Linux, put the following in /etc/default/grub:
Then run:
sudo update-grub

Wednesday, March 29, 2017

SubscribeOn / ObserveOn

Once you have an instance of an IObservable<T> object, Reactive Extensions (Rx) provides at least two points where you can choose an IScheduler which will determine the threading context under which the later operations will run. Those operations can be broken down into two phases: subscription and observation.

Subscription refers to the operations that modify the behaviours of an IObservable<T> (e.g. Throttle, Merge, Concat) The IScheduler for the subscription phase is assigned by the SubscribeOn() method.

Observation refers to the callback operations that are invoked as the result of observing an IObservable<T> (e.g. OnNext, OnCompleted, OnError) The IScheduler for the observation phase is assigned by the ObserveOn() method.

While not the subject of this post, you can also choose an IScheduler implementation to convert any IEnumerable<T> to an IObservable<T> with the ToObservable method. This is relevant when the IEnumerable<T> has the potential to take a long time to be enumerated.

Saturday, March 04, 2017

6 Simple Rules for Async/Await

  1. If a method A calls another method B that returns a Task (or Task<T>) then the calling method does not block on the completion of that task, unless it either:
    1. awaits that task, or
    2. waits on the result of that task
  2. The calling method cannot await a task unless it is declared with the async modifier, which causes the compiler to build a state machine (similar to the IEnumerable iterator) for that awaitable method.
  3. In point 1 above, the behaviour is independent of whether or not B is marked with the async keyword
  4. It is this non-blocking behaviour of A that allows the calling thread to proceed past the point where B is invoked. It's even possible for the thread's call stack to unwind, and for the thread to go back to reading the Windows message queue if it was the UI thread.
  5. The compiler will only warn you "because this call is not awaited ..." if B was marked with async.
  6. It is expected that A will do something with the Task returned by B; at the very least there should be some code to check that the Task did not throw any exceptions. If - instead of B - we have an async method C that returns void then we do not present A with any opportunity to monitor the completion of C. Unobserved exceptions thrown during the execution of C could indicate corrupted program state and can be configured to terminate the application in much the same way that an unhandled exception in synchronous code can unwind a stack fully and terminate the process.