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

Let’s face it, once Christmas is over and done with, the prospect of a long, cold (and this year very snowy) winter looms ahead which can leave us all a bit flat. So, it was great to receive notification that two of iTrinegy’s network emulators had been shortlisted as finalist in the forthcoming 2009 Network Computing Awards.

Every year, Network Computing put forward a selection of network performance and testing technologies and asks its readers to vote for the products they believe should be entered into the finals.

Well, I would like to thank all those readers whose votes mean that we have 2 network emulator products shortlisted. Our INE LCD is a finalist in the Best Testing & Monitoring Product of the Year category, while INE Ultra has been nominated as Best New Product of the Year.

We are in illustrious company as other products in the running come from the likes of Acronis, Juniper Networks, and Network Instruments. Given that our products are quite niche I think it will be “a big ask” to win, but still it’s great to think that enough people value our solutions for us to reach the finals.

If you do feel the urge to cast a vote for us (or any other products, if you must , you can do so at http://www.networkcomputingawards.co.uk/ until 5th March 2009.

Recently, I got myself a 3G “dongle” so I could connect my laptop and be on the Internet anywhere at a “reasonable” speed.  If you haven’t re-visited these gadgets recently you might not have noticed that they’re up from the old 3G speeds of 384Kbps  to 7.2Mbps.  I thought you might like to know my experiences, and of course, being me, I took some measurements…

I went for Vodafone’s 3G USB Modem and Service  which is advertised as up to 7.2Mbps (download – subject to coverage) with a 3GB monthly data limit.  Most of the providers are advertising similar speeds. I went for Vodafone because they had coverage in the areas I wanted.

You get a very neat looking device that looks like a USB memory key, made by Huawei. When I got it home and plugged it in the software installed very easily on my Vista laptop from the USB modem itself, which was also behaving as a USB memory key and a CDROM.  So no extra CDROM to load – nice – well done Vodafone. 

It connected with 2 out of 5 bars (poor – it said) of signal strength and reported a 3G+ connection.  So, better than 384Kbps, but probably not going to be up to the full 7.2Mbps with that signal.

But, I noticed on first use that it was really “sluggish” (technical term) browsing Internet pages.  Sites were taking quite a while to initially connect etc and were slow to navigate around too.  On the other hand, after I navigated (slowly) to the BBC iPlayer web pages I was able to watch an episode of  Top Gear with no pausing to refill the buffer, so the speed was OK for this purpose.  This seemed like our old friends latency and loss at work – something never mentioned in the advertising blurb, which always concentrates on maximum download speed.  This is not Vodafone bashing by the way,  I think this is par for the course for 3G from any vendor, but it proves that the headline numbers which the advertising materials concentrates on aren’t the only important performance factors.

Didn’t have much time that day but generally felt disappointed at the sluggishness, and made up my mind to do some measurements another day.

————————————————————————————–

A friend of mine came round and asked if she could borrow the 3G dongle (for a couple of weeks) last Tuesday.  But I really wanted to do some measuring first, so I said she could have it on Wednesday evening as I needed to do some testing.

————————————————————————————-

7am Wednesday I started and was immediately “disappointed” – it didn’t feel at all sluggish, as it had the other day.  No matter – I think that shows the variability of Wireless Broadband. BTW, my laptop was in the same place give or take a few inches. Here are the numbers:

Signal strength 2 bars (out of 5) – Vodafone UK 3G+

ping google.com   (at 7am) – average time over 20 pings 136ms (Min 128ms, Max 147ms, 0% loss), so way-way more than the 31ms (ish) I get from my cable broadband. A quick tracert to google.com shows that most of this delay is in the first hop i.e. the wireless part.

I was interested in what speedtest.net would say about connection speeds but it was down, so I used Broadbandspeedchecker  instead.  It gave:  Download speed 1328Kbps Upload speed 348Kbp, so no 7.2Mbps, but reasonable.

I then downloaded a file from our web site: www.itrinegy.com.  The 14.3MB file (using http protocol i.e. a standard web site download) took 1 min 53 seconds to download – i.e. 1.012Mbps

————————————————————————————-
My friend came round on Wednesday evening (8:30pm) to collect the dongle but before installing on her laptop I thought I’d have another quick look at the performance on mine.  Sluggish! (Hooray).

“Sorry you’ll have to wait a few minutes – I want to get a few measurements”…

Here are the numbers on this occasion:

Signal strength 2 bars (out of 5) – Vodafone UK 3G+

ping google.com   (at 8:35pm)  ping times were all over the place – the largest value I saw was 1400ms!  Then it settled to between 500-600ms but shortly after was up to an average of 1000ms again.  These are satellite sized round trip times!

Speeds from Broadbandspeedchecker (for a like for like comparison): Download 824Kbps, Upload 323Kbps.   Speedtest.net was working again and gave Download 1510Kbps, Upload 346Kbps (Latency 473). This could have been a difference in when the test was performed, as I said the ping times and therefore probably other performance factors (note the latency of 346 measured by speedtest) were varying greatly. (Or it could have been the method used – I’ll look at that another time).

I repeated the file download (albeit a slightly smaller file) from our web site: www.itrinegy.com.  The 12.1MB file (using http protocol i.e. a standard web site download) took 2 minutes 35 seconds to download – i.e. 624Kbps

————————————————————————————-

So the second result was much more like the experience when I first plugged in the dongle.  Sluggish. But notice that the download speed for my file (624Kbps) and the Broadbandspeedchecker.co.uk download (824Kbps) and speedtest.net (1510Kbps) are not too shabby.

So why this sluggish experience when surfing?  Well, suppose that the latency (which represents a full roundtrip) to google.com averaged 1000ms through the whole test.  That’s a whole second!  If this is the first time we’ve visited a site (so it’s not in our cache) we’ll have to look up the name and get its IP Address – minimum time 1 second, then we have the “three way handshake” to establish the connection: 1.5 seconds  but the browser could do our page request (GET http://…) after 1 second.  Minimum turnaround for the first part of the web page another second.  So we’re at 3 seconds.  If the page needs a css file, graphics etc more seconds… 

So, the conclusion is – download speed here is irrelevant it’s all about latency (delay).

If you want to know your how your applications, web sites etc. might perform in mobile broadband (3G) you can re-create them, without the dongle, using our INE for Windows product.

Happy New Year!

Just before Christmas we exhibited at the TestExpo show, which specialises in tools for testing software.

Chatting with the testers and developers during the show I’m still amazed that when testing, and during the development process itself, the effect of the network on the application being tested/built itself is rarely taken into account at all.

Now, if the application is stand alone or will only ever run in a LAN this doesn’t matter much, as the test and build environments will match the final deployed environment. But if the application is due to run in a WAN (or GPRS, 3G, ADSL, DSL, Satellite or Radio network – I’ll call these all WANs for simplicity) the network really matters, and not just because of limited bandwidth.

Taking the road network as an useful analogy, using a LAN is like having your local town, with all the roads (even your local road) being high speed, multi-lane highways with on/off ramps, no traffic lights etc: fast, capable of taking lots of traffic, unlikely to get congested with minimal delay when getting to any other place. The WAN by comparison consists of a very wide range of roads: multi-lane highways (often congested), single lane highways, lanes, tracks and even muddy fields.

You’d never find a car manufacturer only prototype and test a car on beautifully flat roads if it is intended to go off road. A normal (non 4×4) car wouldn’t get 10 yards in a muddy field!

I think by now most everyone involved in IT understands bandwidth limitations. We’re forever being sold or touted faster home Internet connections, so that we can download faster etc. What most people don’t understand is that latency (delay), loss and errors are very important factors in data transmission across networks. Just as important as bandwidth.

We can get an idea of latency by ping-ing systems both in our LAN and on the WAN e.g. Google and we’ll quickly see that the ping times are very small (<1-3ms) in the LAN and large, sometimes very large in the WAN (e.g. 90ms UK to Eastern USA , >700ms for Satellite). This is the equivalent of a WAN being a long road, with lots of traffic lights, roundabouts, stop signs, muddy even. We can buy more bandwidth (effectively more lanes on the road) but we can’t do much about latency. For TCP based protocols (ftp – file transfer, http/https – web, smtp/pop3/imap – mail transfer, Microsoft DS – Windows file sharing and most custom sockets applications) the delay really matters, as acknowledgements of successful transmission of data must comeback from the other end.

So why don’t they build and test in these WAN (or GPRS, 3G, ADSL, DSL, Satellite or Radio) environments?

One reason is lack of knowledge that it matters. My mission is to change that.

A second is that all that equipment to recreate the WAN, GPRS, 3G, ADSL etc. etc. costs loads and is unmanageable,. which is why iTrinegy exists and produces WAN Simulators/Emulators.