COMP 2221 Networks in Organisations Richard Henson March

COMP 2221 Networks in Organisations Richard Henson March 2014

Week 6: Client-Server, Peer-Peer and Services across the network… n Objectives: Ø Explain the role of the registry in desktop configuration, usability, and security Ø Explain the client-server mechanisms of typical TCP/IP-based network services and reasons why peer-peer networking is not used in most businesses Ø Use appropriate software tools for network services, system/network monitoring and troubleshooting

Rapid Boot-up with Windows 7 (1) n Huge improvements in time to logon screen… Ø 32 -bit colour animation appears at an early stage » driven by the CPU (& using Intel EFI) n graphics card not yet initiated… Ømeanwhile, operating system's kernel and critical device drivers are loading into memory in the background…

Rapid Boot-up with Windows 7 (2) n Early stage of boot process bound to i/o: Øloading the kernel Ødevice driver files Øother system component files n Dimensions of the boot animation limited to a small region of the screen Øavoids i/o delay loading animation images during the early stage of boot…

Rapid Boot-up with Windows n Even better with Windows 8…. or 8. 1? n n

BUT… n In an organisation, the user then needs to log on… Øendless loading of policy files… Øsubsequent configuration to accommodate settings into the local registry…

Why use a network anyway? n All organisations need to control users to some extent Øprovide a useable common desktop Øprovide other services » network printers » applications across the network » web services » email services

The Lure of The Cloud n Can offer: ØStorage » e. g. dropbox ØPlatform-as-a-Service (Paa. S) » e. g. Google App. Engine » incl. operating system, programming language execution environment, database, and web server ØApplications Software-as-a-Service (Saa. S) » salesforce information » shopping cart system

Groups & Group Policy in Domains n Convenient for users to be put into groups ØSettings for group provides particular access to data & services n Problems… Øuser in wrong group(s) Øgroup has wrong settings

Peer-Peer Sharing No Active Directory! n Resources shared through (e. g. ): n ØFile shares ØPrinter shares n Responsibility rests with the administrator of the local machine

Why not Peer-Peer Networks? (formerly known as “workgroups”) n Over to you?

For v Against Peer-Peer n Logon locally only, so… Øno group policies to download! Ømuch faster boot up! Ørun client-server apps n Disadvantages… Øno central accountability! Øusers & computers both difficult to manage Ømore untested software…

Generally agreed that… n Peer-peer networks only possible in very small organisations, where all users are IT-literate and self-reliant Øe. g. group of architects n If network gets larger than 6 -10 users Øuse a domain… (expensive!) Øconsider doing it all in someone else’s domain? (The Cloud… not as cheap as at first glance…)

Controlling User and System Settings… n Arguably the most important part of a network manager’s job Ø get it right: happy users, happy managers Ø get it wrong: » frustrated users… » angry managers…

Local user control and Local Policy Settings ØUsers and groups – exactly the same principle as domain users and domain groups » can set their own policies » applied using local logon ØSystem settings for computer may need to be changed for particular users » e. g. on CRT monitors, lower screen refresh rate for epileptics

What is a Policy File anyway? n Collection of registry settings in a text file Ø appropriate settings for each group Ø can overwrite one another n Can overwrite: Ø local machine registry settings Ø current user registry settings n Group policy files should therefore only be created and used by those who know what they are doing!!!

Trustworthy Software and Client-Server apps n Single machine apps often go wrong. . ØWhy? n What about applications run partly on client, partly on server, with parameter passing (i. e. data transfer) across: Ølocal network? ØInternet? ØCloud?

Specifying a new Client-Server Application? n First of all: ØWhat about stating requirements for software residing on a single machine n Standalone software has often been developed and “missed something”… ØGenerally OK with overtly specified requirements Øproblem with implicit requirements…

Implicit and Explicit Requirements n Typically, customers only really understand/care about Explicit (Functional) Requirements Ø e. g. a Local Authority may want a Bridge New Bridge • The expressed Functional Requirement may only be: • Direction & Length • Capacity (number of lanes) 19 [TSI/2012/183] © Copyright 2003 -2012

Implicit Requirements (NFRs) n In most industries… Ø supplier gives due weight to all relevant guidance » {c. f. Ethical Principles} » including Non-Functional Requirements (NFRs) n NFRs for the Bridge: • Strength (of components & overall) • Clearance required over river • known failure modes - - - - - > n NFRs & software industry? 1 st Tacoma Narrows Bridge 1940 -11 -07 Ø overlooked? !#! Ø not a good track record for Trustworthiness… 20 [TSI/2012/295] © Copyright 2003 -2012

Trustworthy Software Requirements (1) • Explicit (Functional) Requirement for Trustworthiness • list, accurately stated • Implicit (Non Functional) Requirement (NFR) for Trustworthiness • direct NFR for software under consideration • as collateral NFR from other software in environment 21 [TSI/2012/183] © Copyright 2003 -2012

Trustworthy Software Requirement (2) • Requirements cover • whole of ICT (including ICS) • development activities to create the software (Specification, Realisation and Use) • Assurance requirements range • • • Due Diligence (all software) … to “Comprehensive”

Typical NFRs (PAGICC) PAGICC n n n Performance ARM (Availability (incl. Resilience), Reliability (incl. Robustness) & Maintainability (incl. Documentation)) Governance (Legal (incl. IPR), Regulatory, Policy) ILS (Integrated Logistic Support incl. Escrow) Compatibility (Operating Environment, Interfaces, Platforms and Dependencies) Cultural Fit (including Reputation, Brand) 23 [TSI/2012/183] © Copyright 2003 -2012

Typical NFRs (QUESTESS) n n n n Quality (e. g. Faults Delivered, Fault Removal Efficacy) Usability / human factors and Accessibility Evolution (incl. Extensibility / Scalability, PDS (Post Design Services)) Standards TEA (Training, Education and Awareness) Environmental Impact Security (incl. IA, Audit/control and DPA) Safety

Typical NFRs (PAGICC) n n n Performance ARM (Availability [incl. Resilience], Reliability [incl. Robustness] & Maintainability [incl. Documentation]) Governance (Legal [incl. IPR], Regulatory, Policy) ILS (Integrated Logistic Support incl. Escrow) Compatibility (Operating Environment, Interfaces, Platforms and Dependencies) Cultural Fit (including Reputation, Brand) 25 [TSI/2012/183] © Copyright 2003 -2012

Platforms and Software Trustworthiness n Only through extensive testing…. Ø over many years…