The correct way to develop software that utilizes a network still seems to be a little understood subject. The main issue seems to be that there are few people around who have the experience necessary to understand both the correct way to implement/use the necessary network protocols, as well as the implications of running the software over different networks.  This can cause issues with both development and testing: if there is a lack of understanding of the restrictions the network will place on the software then it is not possible to correctly develop or test the software, resulting in a very uncertain outcome.

The principles are pretty simple to grasp though. Essentially the network requirements are derived from performance and usability requirements. If the requirements say that the user should not have to wait for more than 10 seconds for something to happen then you have to factor in how long it will take the data to come across the network. Unfortunately, this is not so simple, as a couple of factors affect this, such as where the servers are located in relation to the user (e.g. the user could be in one city and the server in another city) and the amount of bandwidth that will be available to the user. If the user and the server are a significant distance apart then it is going to take a noticeable amount of time for the request to get to the server and then the data to come back the other way. If there is more than one request/response then this delay is multiplied and  can start to have a very significant impact on the amount of time it will take for the application to respond to the user.  If there is a bandwidth restriction (and I’m referring to the “available bandwidth” here, not the theoretical link maximum) then it is important to allow for this; if the software needs to download several megabytes and the user only has a 1mb/s available then it is going to take some time.

There are two main protocols on the internet which almost everything else is built on top of – TCP (used by HTTP – the web, FTP, etc) and UDP (used by Video/Voice streaming, DNS, etc). TCP is reliable, this means that as long as the connection is valid data will be delivered, eventually (possibly after several retries). UDP is unreliable, this mean that if the data is lost or damaged along the way, due to too much data being on the network or other issues, then the user will never receive it.  It is important that the right protocol is used for your application, typically TCP where you need to guarantee data delivery will be used but UDP can be better if the data loss can be tolerated, or retransmitting data is irrelevant as will be out of date.

One final thing to think about is how many users are going to access the server software at the same time. If there are going to be hundreds or thousands then the server application must be able to cope with this gracefully and not just assume that the computer and network resources are unlimited. The server software should then have maximum limits for each resource so that in the event of a large surge in demand the server software will not crash and will break the host computer. It should be possible to determine the amount of resource each connection is likely to use depending on the action the client has requested.  Using this data the computer and network can be correctly specified.
Below are a list of requirements/recommendations that should be incorporated into any software development and, if followed and properly tested, will help to ensure that the application is far more usable/robust:

1. Make as few requests as possible to the server.  Bunch requests together so that the server can respond to them all at the same time
   • This prevents the user having to wait due to the latency between the user and the server.
2. If more than a set amount of time goes by (say 2 to 5 seconds) and the required data has still not been fully received ensure the user is updated so that they know something is happening.
3. If there is no response from the server in a set amount of time then allow the user the chance to cancel the request
4. Be prepared for the connection to break mid way through a request and alert the user as required without crashing the software
5. Allow for the data to come in at irregular intervals.  Just because the data is coming in a 100KB/s for the last two seconds it does not mean that it will carry on (it’s the stock markets famous phrase – past performance is no indication of future returns…).
6. Do not allow the GUI to freeze just because data is being transferred across the network.
   • This is the one that bugs me the most – and ends up with MS Windows saying that the application is no longer responding
7. Place limits on what the server software can use to ensure that it does not crash and that it does not crash the host computer
8. Just because your application does not specifically use the network, if it can write to network share (e.g. gives the user a choice of where to save the file) then it has to take account of the amount of time the write (or read) could take.
9. Test how the application will perform on a variety of different network conditions – just testing locally will in no way help you to determine how it will perform when the user is in another city or working from home, or another country, or on the road, etc.
   • As you’re unlikely to be able to test in the live network, or get it to “misbehave” (have low available bandwidth, disconnect, lose data) to order, you may want to think about using a network emulator in your development and testing

With the World Cup just around the corner, you may be tempted to catch a match live while at work by watching streaming media over your computer. However, today our UK office received a letter from the TV Licensing Agency which may stop you in your tracks if your offices are located in that country.

The letter advises that “…if your staff or customers watch television programmes as they are being shown on TV, including live World Cup games, then your organization needs to be covered by a TV licence.  This is the case whether they use a laptop, computer, TV set, mobile (cell) or any other device owned by your business”.

The key phrase here is  “owned or provided by your business” as the letter goes on to advise of an exception. Apparently, if your staff watch television programmes as they’re being shown on  television USING THEIR OWN DEVICE, and they haven’t connected it to the mains or an aerial, then they’re covered by their own home TV Licence, if they have one.

A full explanation of the situation is available on the TV Licensing agency web site  http://www.tvlicensing.co.uk/check-if-you-need-one/business-and-organisations/

Of course, the quickest way to ensure your organization doesn’t fall foul of this regulation is to either buy a licence or impose a blanket ban on anyone watching TV while at work. However, for some fans it’s going to be really hard to resist just taking a quick look online using office equipment.  Alternatively, they may decide to bring in their own devices.

Either way, if you are an owner, director or manager you need to know what is being accessed over your company’s network in case, at worst, it is illegal or more innocently (but probably of greater significance) impacting the performance of other networked applications.  This is where you may find our AppQoS monitoring products useful as they can show you how the network is being used and who’s accessing what, including World Cup TV.

We really wish our team well and hope that this is the year when we bring home the World Cup, while at the same time ensuring we all stay on the right side of the regulations.

Last month, I was approached by the BCS (British Computer Society) to get involved in a televised panel session to discuss the implications of adopting a Cloud Computing strategy (SEE ”DEBATE” LINK BELOW). We spend a lot of time advising organizations that they can’t ignore the importance of how applications perform over “non-LAN” networks and “The Cloud” is certainly one of these. So, I thought this would be the perfect opportunity to raise the nature of the network in “Cloud” delivery as an issue that companies embarking on a Cloud Computing implementation need to really think about.

The debate quickly revealed that Cloud Computing really does mean different thing to different people. For some, it means Software as a Service (SaaS), where applications are hosted by the author (or hosting service on the author’s behalf). This is becoming really popular, particularly with smaller companies where the economies of scale possible for vendors like Google with Google Apps, Salesforce.com etc can make these applications hugely cost effective. Others extend the definition to include Platform as a Service (PaaS) – where you can build and host your application using the providers tools and infrastructure, like appforce.com. For some Cloud Computing is simply Infrastructure as a Service (IaaS), or even hosting! And there are even more definitions where a vendor has simply noticed that there’s a lot of “buzz” around the term Cloud and so they must use it in their marketing.

Regardless of which definition you may wish to apply, the success or otherwise of implementing a Cloud Computing model, will rely heavily on the performance of the application running over the network the user is going to use to access the Cloud Computing-based solution. Where the application is going to be hosted relative to the end-user (same country, same continent, different continent) is going to have an impact on its performance. Things such as available bandwidth, latency and loss will all influence application performance. However this, as the DEBATE shows, is something that seems to be just one of a great number of items that need to be added to the Cloud Computing checklist. However, it really is one that I believe you simply can’t ignore – you may be able to control or determine the hosts and even specify minimum performance (cpu, memory etc) on the clients but the network, particularly when public is much harder to control and the application needs to perform reasonably even when the network is under stress.

I had a debate with one of our customers the other day on how to measure latency in their network.

You may wonder why this even matters:  Well, as I outlined in a previous blog, for almost all TCP based applications (Mail, Web, ftp, custom sockets applications…) latency matters just as much, or more, than bandwidth.  If bandwidth is the “speed of our road”, then latency is the “journey time”, which is related to “the length of the road” as well as all the “holdups” (competing traffic, delay at routers, switches, repeaters etc) along the way.  If we want to test how an application will work in a real network using a network emulator then we need to understand the latency, bandwidth etc that it will experience.

The simple and traditional answer in measuring latency is to use ping, or a tool based on ping or its underlying protocol ICMP.  These send an ICMP  packet to the destination which it turns around and sends back and the round trip time (RTT) is calculated.  But this has problems in most modern networks! 

Why?  This is due to most modern networks, the Internet, corporate WANs, and MPLS included, implementing some form of traffic prioritisation (or QoS – Quality of Service- as it’s often known).  This has been done so that important applications, such as corporate VoIP, SAP etc receive preferential handling and others, such as access to iPlayer etc receive a low priority.  The problem with Ping (ICMP) is that it receives no particular priority at all, and so is not really representatitive of a particular application. 

I don’t mean to diss ping completely – sometimes it’s all we’ve got, but the way around this is to measure the latency of “real” application traffic which is subject to the appropriate network QoS.   To do this we can take advantage of the fact that when a TCP connection is made, and before any http, ftp etc. request is made, or data is sent, a handshake (known as the three way handshake) takes place between the client and the server.  

Using some maths on this we get to see the latency for presisely that application, as the handshake packets are subject to all the QoS parameters of the rest of the TCP session.

You could therefore take the approach of trying to create a TCP session to a target server using the correct IP addresses and ports and time the handshake, but this might cause problems for the server, and as we’re unlikely to complete the transaction it could be regarded as a potential intrusion or DoS (Denial of Service) attack.

Because of this, in our INE Companion and iTrinegy AppQoS products, we provide the ability to “watch” the normal, existing  transactions taking place and time their handshakes.