THE MOBILE NETWORK - Throughput and Latency

Although these acronyms and the constant evolution of cellular and wireless network technology
can be baffling, the important thing to understand is that a variety of networks are used to provide data connections to your users ’ devices. As with the physical and diversity - related challenges of the devices themselves, you need to be cautious about assumptions for these connections.

Speed or throughput of the network connection is an obvious constraint. At the end of 2010, according to Akamai, the average fi xed - line broadband speed in the United States was 5Mbps,
many factors faster than even the theoretical peak speed of most mobile networks. This has a direct impact on the users ’ Web experience because it defi nes the minimum time that an uncached web page takes to download to a device. You ’ re probably not surprised to read that many mobile devices also do not have comprehensive or long - lived caching capabilities, thanks to their memory constraints.

A user with a 3G UMTS connection in the United States might expect an average download speed of 250Kbps, and 750Kbps on HSDPA (although such speeds are drastically affected by movement and the density of other data users in the local area). Even this is six times slower than a typical wired desktop experience: A web page containing a 1Mb video fi le might load in 2 or 3 seconds on a desktop, but it would take at least 15 seconds on a fast mobile network. That may be longer than an impatient user on the go is prepared to wait for the download. If you expect to deliver rich media to your mobile web users, you certainly need to look at limiting or adapting fi le sizes.

In addition to pure speed, other factors significantly affect the impact of the network on the user
experience. One is the setup time for the data connection itself. A desktop or laptop computer
usually has a persistent connection to the Web, and the fi rst page visited by a user starts to
download immediately. Most devices, on the other hand, connect on demand (in order to preserve power when the data connection is not in use), and this can add as much as 5 to 7 seconds to the time for the first page to be requested. Your users may already be impatient by the time your page even starts downloading.

A more persistent but often overlooked consideration is that of roundtrip latency. This is a
measure of the time taken for data packets to proceed from the device, through the network, to
the destination service, and back again, although excluding the time actually taken for the server
to perform any processing. This is influenced entirely by the type and topology of the network, the route the packets take, and any intermediate proxies or gateways that process the data en route.

On a fixed - line ADSL connection, latency is so low that it is barely considered. Regardless of the throughput speed, a ping time of less than 80 milliseconds to most web servers can be assumed from within the United States, and at most a few 100ms to internationally hosted servers.

On a mobile network, however, latency is a real consideration. This is partly because packets
sent from a mobile device to a public web server traverse a number of sub - networks and their
boundaries. First, there is the cellular air interface to a nearby cell station — which has a
particularly significant impact on latency — then a backhaul link to the network carrier ’ s switching center. Then there is a sequence of gateways that connect the traffic, often through firewalls and proxies, to the Internet, and then finally the packet proceeds through web infrastructure to the server. The effects on latency can be significant.

AT & T quotes a latency overhead of between 100ms and 200ms for requests to servers immediately external to their current UMTS and HSDPA networks, and 600ms over their GPRS and EDGE networks. While this is impressive, given the complexity of the cellular network involved, you should still expect the latency of a typical browser - to - server - to - browser roundtrip to be an order of magnitude longer than for a broadband connection.

In some respects, latency is more important than the raw throughput of the network, and this is particularly true for web applications, where a page is made up of a large number of component
parts. The request for each graphic, each style sheet, and each external script is delayed by the latency of the network, and if those objects are small, this can easily dominate the total time taken for the page to fully download. Web developers can take real action to mitigate these effects, such as combining CSS files, using sprite techniques for interactive images, and tuning cache settings for external objects.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

THE MOBILE NETWORK - Data Networks

As you might imagine, the networks responsible for bringing content and services to a mobile device are also notably different from the networks to which you connect laptops and desktops. Many contemporary mid - and high - end mobile devices include WiFi data connectivity, and when used in that mode, the device is connecting to a local access point, which, in turn, is most likely connected to a regular broadband - grade connection. In this case, the network connection for the device is fast, reliable, and low in latency — just as it is for the other computers and devices that are connected through the same access point and service provider.

But leave the limits of the hotspot, and your mobile device needs to revert to the cellular network for its data connection. At this point, the behavior and characteristics of the connection can change dramatically. A responsible web developer needs to be aware of these likely characteristics — and how the device mitigates them — in order to ensure that the user still retains a pleasant experience.

Throughout the world, a small number of prevalent cellular and mobile data technologies are in
regular use. The most widespread, by both geography and number of users, is the Global System for Mobile Communications (GSM) and its evolutions, which provide over 4 billion connections in over 200 countries worldwide, including the United States. A rival family of standards, broadly termed CDMA, is also popular in the United States, China, and a number of other countries. Japanese networks offer particular implementations of various types, including some proprietary network technologies.

In most developed and some developing markets, network technologies have reached a third -
generation of data access, sometimes known as 3G, providing speeds up to 2Mbps. These include UMTS (also known as W - CDMA), generally deployed by GSM network carriers, and CDMA2000, deployed by their CDMA brethren. In the United States, AT & T and T - Mobile offer UMTS data networks, while Verizon and Sprint have CDMA2000 networks.

Markets that have not yet reached widespread 3G coverage but still provide data services (notably in the least - developed countries and many developing countries), tend to provide slower 2.5G or 2.75G data technologies. Most common of these are the GSM - based GPRS which provides speeds up to 60Kbps, and EDGE which provides speeds up to 240Kbps.

Looking forward, fourth generation mobile technologies, including Advanced Long Term Evolution (LTE), are, at time of writing, in the process of being specified and standardized, but theoretically offer speeds up to 1Gbps. Sadly, such networks and devices are unlikely to be widespread for several years. In the interim, many networks provide transitional 3.5G technologies, such as HSDPA, EV - DO, and WiMAX, all of which, with speeds of between 3Mbps and 14Mbps, offer significant increases of speed and capacity to the 3G platform.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

Less than 5 years ago, when most mobile devices used their own embedded or simple real - time operating systems, it appeared to mobile web developers as though there were as many operating system versions as there were models of devices. Given that these operating systems tended to
contain their own varied browser implementations, with no option for users to upgrade them or install alternatives, the challenge of delivering a reliable web experience to all of them was almost insurmountable. Such browsers were typically very limited, and often derived from their WAP browser precedents, provided limited or incomplete XHTML or CSS capabilities, low - fidelity media support, and little or no opportunity to use JavaScript or AJAX in web pages.

In 2005, Opera, a Norwegian browser manufacturer, launched Opera Mini, a browser that could be installed by the user on such devices and which subsequently has become a very popular third - party browser for older and low - to mid - range handsets. (Opera also provides a more capable browser, Opera Mobile, which runs on high - end devices, primarily those running Symbian and Android.) Using a proxy architecture to compress, adapt, and re - layout the content on behalf of the device, this browser provided the first glimpse that rich and complex websites could be rendered well and made relatively usable on a typical mobile device screen.

At about the same time, Nokia released a new browser for their high - end S60 range of devices that was based on code from the open - source WebKit browser project. Given its desktop heritage, the WebKit engine provided an unprecedented level of support for HTML, CSS, and JavaScript on a mobile device. This was something of a watershed in the history of mobile browsers, and since then, a number of signifi cant mobile device platforms now ship with WebKit - based browsers, including Apple ’ s iPhone, Google ’ s Android, Palm ’ s WebOS, and most recently Blackberry. Microsoft ’ s mobile operating systems do not provide WebKit - based browsers, but the capabilities of their default browsers have risen significantly in recent releases.

While the different implementations of each of these browsers can vary radically — device diversity is not going away any time soon — they do at least share a common open - source ancestry. This has helped the cause of efficient mobile web development greatly, because a developer or designer can at least assume a reasonable level of support for image and media support, CSS, and AJAX (although not Flash, video, or vector graphics, which remain variable in their support across browsers).

Unfortunately, it ’ s easy to forget that not all users are necessarily running the latest and greatest smart phones. Many cheaper handsets still run on embedded operating systems with weak web.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

Pick up any mobile device and look at it carefully. Of course, the first thing you notice is the size, shape, and weight of its physical implementation. Very old mobile devices can be easily recognized by their larger, ungainly form, but following a period in the 1990s and 2000s, during which manufacturers sought to develop ever smaller devices, most modern devices are now of broadly similar size and weight. Not by coincidence, this is about the size that fi ts comfortably into an adult hand.

A limited selection of device form factors tend to prevail in today ’ s mobile market place. Some are more popular in certain parts of the world than others or among certain demographic groups, so a conscientious mobile web developer needs to be aware of all of them. These broad categories include the following:

Candybar — These devices are rectangular and static, typically with the main screen on the top half of one face and navigational control keys and a numeric keypad on the lower part of the same face, as with the Samsung SGH - t349. This form factor tends to be prevalent for cheaper or legacy models, although a wider, flatter candybar form, with a larger screen and complete QWERTY keyboard, is often used for more pricey business devices, such as the RIM BlackBerry range and some of the Nokia E - Series range.

Slate — These devices are also rectangular and static, but with much larger screens and fewer physical buttons on the casing than the candybar form factor. The rise of popularity in slate devices has been largely driven by improvements in touch - screen technology, which allow for point - and swipe - based navigation and for numeric and QWERTY keyboards to be displayed in software. Often, these devices can be rotated between landscape and portrait mode to maximize screen usage for particular types of applications. With the advent of the Apple iPhone and Android - based devices, this form factor has become very popular on expensive consumer
devices, although some mid - range devices are now exhibiting similar characteristics. Additionally, a larger variant of the slate form factor, personified by the Apple iPad, Amazon
Kindle, and other tablet devices, is starting to inhabit the space between pocket - sized mobile devices and laptops, while still being quite feasible web clients for humans on the move.

Slider — These devices are rectangular and of similar proportions to candybar devices when closed. However, the two halves of the device, one supporting the screen and one the keyboard, are able to slide relative to each other. This extends the size of the device and exposes the keyboard for use. Portrait - style sliders are popular, often on low - end models, because the longer “ open ” shape can be easier to use for making calls. However, many contemporary handsets slide in a landscape manner, exposing a QWERTY keyboard to use with a wider screen aspect ratio, as with the HTC P4350 device shown.

Flip — These devices also are designed to open up and expose a concealed keyboard, but do so with a hinge, rather than a slider. As a result, the primary screen is not visible in the closed state and is generally smaller as a proportion of the device than for the other form factors. Some handsets provide a smaller secondary screen on the outside of the device, but this rarely supports a web browser. Motorola i410 device exhibiting a classic flip form. Despite all the differences between these form factors, you need to make some reasonable assumptions for the purposes of delivering mobile web content to a capable device. First, you can be fairly sure that the device has a screen upon which its browser can render your content, but also that it is fairly small, both physically and in terms of pixel dimensions — relative to a desktop or laptop.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

What's in It for Developers?

Your ability to write a webbot can distinguish you from a pack of lesser developers. Web developers—who've gone from designing the new economy of the late 1990s to falling victim
to it during the dot-com crash of 2001—know that today's job market is very competitive. Even today's most talented developers can have trouble finding meaningful work. Knowing how to write webbots will expand your ability as a developer and make you more valuable to your employer or potential employers.

A webbot writer differentiates his or her skill set from that of someone whose knowledge of Internet technology extends only to creating websites. By designing webbots, you demonstrate that you have a thorough understanding of network technology and a variety of network protocols, as well as the ability to use existing technology in new and creative ways.


Webbot Developers Are in Demand
There are many growth opportunities for webbot developers. You can demonstrate this for yourself by looking at your website's file access logs and recording all the non-browsers that have visited your website. If you compare current server logs to those from a year ago, you should notice a healthy increase in traffic from nontraditional web clients or webbots. Someone has to write these automated agents, and as the demand for webbots increases, so does the demand for webbot developers.

Hard statistics on the growth of webbot use are hard to come by, since many webbots defy detection and masquerade as traditional web browsers. In fact, the value that webbots bring to businesses forces most webbot projects underground. I can't talk about most of the webbots I've developed because they create competitive advantages for clients, and they'd rather keep those techniques secret. Regardless of the actual numbers, it's a fact that webbots and spiders comprise a large amount of today's Internet traffic and that many developers are required to both maintain existing webbots and develop new ones.


Webbots Are Fun to Write
In addition to solving serious business problems, webbots are also fun to write. This should be welcome news to seasoned developers who no longer experience the thrill of solving a problem or using a technology for the first time. Without a little fun, it's easy for developers to get bored and conclude that software is simply a sequence of instructions that do the same thing every time a program runs. While predictability makes software dependable, it also makes it tiresome to write. This is especially true for computer programmers who specialize in a specific industry and lack diversity in tasks. At some point in their careers, nearly all of the programmers I know have become very tired of what they do, in spite of the fact that they still like to write computer programs.

Webbots, however, are almost like games, in that they can pleasantly surprise their developers with their unpredictability. This is because webbots operate on data that changes frequently, and they respond slightly differently every time they run. As a result, webbots become impulsive and lifelike. Unlike other software, webbots feel organic! Once you write a webbot that does something wonderfully unexpected, you'll have a hard time describing the experience to those writing traditional software applications.


Webbots Facilitate "Constructive Hacking"
By its strict definition, hacking is the process of creatively using technology for a purpose other than the one originally intended. By using web pages, news groups, email, or other online technology in unintended ways, you join the ranks of innovators that combine and alter existing technology to create totally new and useful tools. You'll also broaden the possibilities for using the Internet.

Unfortunately, hacking also has a dark side, popularized by stories of people breaking into systems, stealing private data, and rendering online services unusable. While some people do write destructive webbots, I don't condone that type of behavior here. In fact, KEEPING WEBBOTS OUT OF TROUBLE is dedicated to this very subject.

Source of Information : Webbots Spiders and Screen Scrapers A Guide to Developing Internet Agents with PHP CURL

How to Use OpsMgr

Using OpsMgr is relatively straightforward. The OpsMgr monitoring environment can be accessed through three sets of consoles: an Operations Console, a Web Console, and a command shell. The Operations Console provides full monitoring of agent systems and administration of the OpsMgr environment, whereas the Web Console provides access only to the monitoring functionality. The command shell provides command-line access to administer the OpsMgr environment.


Managing and Monitoring with OpsMgr
As mentioned in the preceding section, two methods are provided to configure and view OpsMgr settings. The first approach is through the Operations Console and the second is through the command shell.

Within the Administration section of the Operations Console, you can easily configure the security roles, notifications, and configuration settings. Within the Monitoring section of the Operations Console, you can easily monitor a quick up/down status, view active and closed alerts, and confirm overall environment health.

In addition, a web-based monitoring console can be run on any system that supports Microsoft Internet Explorer 6.0 or higher. This console can be used to view the health of systems, view and respond to alerts, view events, view performance graphs, run tasks, and manage maintenance mode of monitored objects. New to OpsMgr 2007 R2 is the capability to display the health explorer in the Web Console.


Reporting from OpsMgr
OpsMgr management packs commonly include a variety of preconfigured reports to show information about the operating system or the specific application to which they were designed to work. These reports are run in SQL Reporting Services. The reports provide an effective view of systems and services on the network over a custom period, such as weekly, monthly, or quarterly. They can also help you monitor your networks based on performance data, which can include critical pattern analysis, trend analysis, capacity planning, and security auditing. Reports also provide availability statistics for distributed applications, servers, and specific components within a server.

Reports are particularly useful for executives, managers, and application owners. These reports show the availability of any object within OpsMgr, including a server, a database, or even a service such as Lync Server 2010 that includes a multitude of servers and components. The availability report in Figure 13.6 shows that the LS1 Server was available until after 8:00 a.m. and then was down through 11:00 a.m.

The reports can be run on demand or at scheduled times and delivered through e-mail. OpsMgr can also generate HTML-based reports that can be published to a web server and viewed from any web browser. Vendors can also create additional reports as part of their management packs.


Using Performance Monitoring
Another key feature of OpsMgr is the capability to monitor and track server performance. OpsMgr can be configured to monitor key performance thresholds through rules that are set to collect predefined performance data, such as memory and CPU usage over time. Rules can be configured to trigger alerts and actions when specified performance thresholds have been met or exceeded, enabling network administrators to act on potential

performance issues. Performance data can be viewed from the OpsMgr Operations Console. In addition, performance monitors can establish baselines for the environment and then alert the administrator when the counter subsequently falls outside the defined baseline envelope.


Using Active Directory Integration
Active Directory integration provides a way to install management agents on systems without environmental-specific settings. When the agent starts, the correct environmental settings, such as the primary and failover management servers, are stored in Active Directory. The configuration of Active Directory integration provides advanced search and filter capabilities to fine-tune the dynamic assignment of systems.


Integrating OpsMgr Non-Windows Devices
Network management is not a new concept. Simple management of various network nodes has been handled for quite some time through the SNMP. Quite often, simple or even complex systems that use SNMP to provide for system monitoring are in place in an organization to provide for varying degrees of system management on a network. OpsMgr can be configured to integrate with non-Windows systems through monitoring of syslog information, log file data, and SNMP traps. OpsMgr can also monitor TCP port communication and website transaction sequencing for information-specific data management.

New to OpsMgr 2007 R2 is the capability to monitor non-Microsoft operating systems
such as Linux and UNIX, and the applications that run on them, such as Apache and
MySQL. OpsMgr monitors the file systems, network interfaces, daemons, configurations,
and performance metrics. Operations Manager 2007 R2 supports monitoring of the following
operating systems:

. HP-UX 11i v2 and v3 (PA-RISC and IA64)
. Sun Solaris 8 and 9 (SPARC) and Solaris 10 (SPARC and x86)
. Red Hat Enterprise Linux 4 (x86/x64) and 5 (x86/x64) Server
. Novell SUSE Linux Enterprise Server 9 (x86) and 10 SP1 (x86/x64)
. IBM AIX v5.3 and v6.1

Special connectors can be created to provide bidirectional information flows to other management products. OpsMgr can monitor SNMP traps from SNMP-supported devices as well as generate SNMP traps to be delivered to third-party network management infrastructures.


Exploring Third-Party Management Packs
Software and hardware developers can subsequently create their own management packs to extend OpsMgr’s management capabilities. These management packs extend OpsMgr’s management capabilities beyond Microsoft-specific applications. Each management pack is designed to contain a set of rules and product knowledge required to support its respective products. Currently, management packs have been developed for APC, Cisco, Citrix, Dell, F5, HP, IBM, Linux, Oracle, Solaris, UNIX, and VMware to name a few.

. A complete list of management packs can be found at the following Microsoft site:
http://pinpoint.microsoft.com/en-US/systemcenter/managementpackcatalog.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner