RTCAST Lightweight Multicast for Real-Time Process Groups

LANDesk® Management Suite 8.8 Best Practices for Provisioning – Unattended InstallContentsSummary (4)Assumptions (4)Advantages of Provisioning (4)Automating Provisioning (5)Deploying a PXE representative (5)Steps to deploy the PXE Representative (5)About Templates (6)About Provisioning Agent (6)Unattended Install (7)Provisioning History (20)Adding a bare metal device (21)Provisioning Rights (22)Conclusion (22)References (22)Acronyms (22)About LANDesk Software (23)Author (23)This document contains confidential and proprietary information of LANDesk Software, Inc. and its affiliates (collectively “LANDesk”) and is provided in connection with the identified LANDesk® product(s). No part of this document may be disclosed or copied without the prior written consent of LANDesk. No license, express or implied, by estoppel or otherwise, to any intellectua l property rights is granted by this document. Except as provided in LANDesk’s terms and conditions for the license of such products, LANDesk assumes no liability whatsoever. LANDesk products are not intended for use in medical, life saving, or life sustaining applications. LANDesk does not warrant that this material is error-free, and LANDesk reserves the right to update, correct, or modify this material, including any specifications and product descriptions, at any time, without notice.Copyright © 2007, LANDesk Software Ltd. All rights reserved.LANDesk and Targeted Multicast are trademarks or registered trademarks of LANDesk Software, Ltd. and its affiliated companies in the United States and other countries. Other brands and names may be claimed as the property of others.LSI-0614 04/07 JBB/NHThe purpose of this document is to provide a simple approach to setting up and configuring LANDesk® Provisioning for an unattended installation of Windows XP. LANDesk® Provisioning provides a new way to completely install and configure your desktops and servers—from OS installation to application deployment, patching and configuration—all using a single provisioning task. LANDesk Provisioning was built with the IT administrator’s environment and workflow in mind, providing the standardization and repeat ability you need, while allowing for the customization and flexibility you must have to meet your end users’ needs.LANDesk provisioning allows you to split the provisioning tasks the way you split the work when you’re setting up a system manually now. You can:Plan and assess the needsDesign and test the system configurationDeploy to one or to a group of systemsCreate reusable ―building block‖ tasks for common operationsPerform post-OS tasks, such as installing applications, updating the virus definitions file, and updating the OS with patches Ensure the installation worked, perhaps by running sample test applications.You can schedule a provisioning task in advance—even before the hardware arrives on site—or run it dynamically when needed, such as when a system fails and needs to be restored in-line.Provisioning consists of defining the attributes and features to be applied to targeted servers via automation. This is done through provisioning templates. A template is a series of building blocks to be applied to a device. They build upon each other, and can consist of actions, attributes, constraints, and so forth. A template can have one or many actions. Templates can be re-used, and components of a template can be copied to another. LANDesk provides some canned templates for you to download to modify for your environment.Note: This document is not a complete source of all LANDesk provisioning information. For more detailed information, please see the online help when using your LANDesk management solution.AssumptionsThis paper assumes that the reader has a working knowledge of LANDesk® Management Suite, its functionality, profile migration and operating system deployment methods.Advantages of ProvisioningLANDesk Provisioning offers several advantages over the current practice of manual installs or creating and managing a library of images for new devices. Provisioning defines a series of actions and attributes that are applied to a device dynamically, known as templates. Templates can be defined in either large or small portions and can be combined together to be customized for different hardware and application-types.Creating multiple custom templates using LANDesk’s provisioning capabilities is faster and easier than creating multiple cust om images. Say you have to create 30 unique configurations for your environment. Since templates are formatted as XML documents, and actions can be shared between templates, you can easily review and edit templates for consistency rather than rebuilding or recapturing 30 unique images. For example, if you create an action that installs the virus scanner and updates definitions, you can share this action with each of the 30 templates.If you have a library of images already created, LANDesk provisioning can make use of those images, then script actions before the image deployment—such as waking and booting a remote device—and after the image—such as downloading updated definitions files and OS updates.Templates can be created and scheduled in advance—before the hardware arrives on site. Because each system is unique, sharing a general image between systems can lead to performance and compatibility issues that scripted installs can overcome, so doing this kind of pre-arrival prep work with images. Further, by combining various ―building block‖ templates, new templates can quickly and easily be created and customized to meet a system’s exact requirements.Automating ProvisioningManual provisioning traditionally offers some advantages to the IT administrator, allowing him or her to handle odd error conditions or find needed device drivers so the IT admin is assured of a successfully provisioned device, rather than devoting hours to programming ultra-complex custom scripts that may yield little return when the time spent programming and troubleshooting the scripts is taken into account.When you have only a few devices coming online every month or you have a store of images to go on several identical devices, a manual or semi-automated provisioning process can seem manageable, but it still lacks the benefits an automated install offers, including:RepeatabilityRemote installDeployment and installation task logging for expedited problem solvingSingle process for push and pullSavings through fewer on-site visits and waking powered-off machines for installation.This paper walks you through using LANDesk’s management pro ducts to provision systems from a bare metal hardware to fully configured software automatically; or to re-provision existing systems to new software or OS configurations.Deploying a PXE representativePXE is an industry-standard networking protocol that enables devices to be booted and imaged from the network, by downloading and installing an executable image file from an image server before the device boots from the local hard drive. On a PXE-enabled device, the PXE protocol is loaded from either the net work adapter’s flash memory or ROM, or from the system BIOS. The lightweight PXE representatives in LANDesk management solutions eliminate the need for a dedicated PXE server on each subnet.PXE-based deployment provides an alternate method to agent-based deployment for the remote imaging of network servers. With PXE support, administrators can boot both new and existing PXE-enabled devices, and then either execute an OS deployment script at the device from a custom PXE DOS boot menu or use the LANDesk scheduler to schedule an image deployment job.A PXE representative first needs to be deployed because the installation will be run from the PXE WinPE environment. A PXE representative can be deployed to a client that has the distribution management agent installed.Note: We recommend that the PXE representative be deployed to a different machine than the core.Steps to deploy the PXE Representative1.In the console, click Tools | Distribution | OS Deployment.2.In the Operating system deployment window, click the all other scripts tree item. From the PXE representative deploymentscript's shortcut menu, click Schedule.3.In the console's network view, select the target device on which you want to install PXE services.4.Drag and drop the selected device to the PXE Representative Deployment task in the Scheduled tasks window.About TemplatesA template is a series of actions or building blocks to be applied to a device in a particular order. A template can have one or many actions. You can change the task order in a template. The action sequence can be changed where the action makes sense, but cannot be changed where it does not make sense (for example, one cannot place a post-OS-specific action before the installation of the OS). There are numerous pre-configured templates for various vendors (HP, Dell, and so forth). Templates are stored as XML in the database.About Provisioning AgentLANDesk Provisioning is built around an agent called ldProvision that does the following:Provisioning agent that resides on the target systemRequests the provisioning task from the coreThe agent can work with a PXE server, or with Boot Media (physical/virtual).Does not require unique boot media for each targetVersions for both WinPE and LinuxPERecords transactions and reports statusProvides interface to action handlersUnattended InstallThe following steps provide a step by step example of how to prepare the hard drive, start the unattended install and end with installing the LANDesk agent. Additional actions can be added but for simplicity, I have elected to do the basic steps for imaging a machine end to end.Preparing the hard drive1.From the Management Console, open the Operating System Deployment tool and expand the My Templates section underProvisioning Templates.2.Right click on ―All my templates‖ and select New Template.3.Give the Template a name that represents what we are doing such as ―Format Drives‖ and select ―Windows PE‖ for the Bootenvironment and ―Windows XP Pro‖ for the Target OS (This example is for XP Pro) and click OK.4.Right click the Pre-OS installation section and select ―Add Action‖.5.Give the action a name an d select the ―Partition‖ action under the Type section (Partition – Remove All for this example).6.Change the Action type to ―Remove all partitions‖ and type in a ―0‖ for the disk ID as shown below.7.Add a new partition action and select ―Create partition‖under Action type and a ―0‖ for the disk and ―primary‖ for the typeof partition.8.The Size and Offset should be set to ―0‖ to accept the default Offset and the maximum size of disk 0 (These are the wildcardcharacters for these fields).9.Add a new part ition action and select ―Mount partition‖ under Action type and a ―0‖ for the disk, ―1‖ for the Partition ID and―C:‖ for the Logical disk drive-letter to create.10.Add a new partition action and select ―Make bootable‖ under Action type and a ―0‖ for the disk and ―1‖ for the Partition ID.Check the ―Bootable‖ box if this partition should be set to bootable.11.Add a new partition action and select ―Format partition‖ under Action type and a ―C:‖ for the Logical disk drive-letter and―NTFS‖ for the file system. Check the ―Quick Format‖ box for a quick format to be completed instead of a full format.Copy Drivers and Scripted Install1.For this section, it is important to have the unattend.txt file importing into the database and the variables to be used as well.2.Click the ―Public Variables‖ button in the Console as seen below to add some variables that will be needed in later steps.e the Public variables section to view and set global variables that apply to all provisioning templates. Such variables areused to customize template file names to copy, paths to install to, sensitive data such as passwords or product keys or IP addresses to export files from. User variables (variables that apply to only one template) take precedence over publicvariables.4.For this example we will be using variables for the computer name, product ID and password.5.Click ―Add‖ and name the variable ―ldpassword‖, the Type to ―Sensitive data‖ and enter in the password to be used to mapdrives and set the admin password on the device.Note: The benefit of using variables for passwords is that the password will not become compromised and if the password ever changes, the variable can be reset to use the new password instead of having to change it in ever template andconfiguration file.6.Cli ck ―Add‖ and name the variable ―ProductID‖, the Type to ―Sensitive data‖ and enter in the volume license product ID.7.Click the ―Install Scripts‖ button in the Console as seen below to insert the unattend.txt to be used for the scripted instal l.8.The ―unattend.txt‖ script to be imported should have the variables for the password, product ID and device name. For thisexample, we will copy over the PnP drivers to be used before executed the scripted install so the drivers to be added will need to be somewh ere on a share and mentioned in the unattend.txt under the ―OemPnPDriversPath‖ section.Example unattend.txt:9.Browse to the File, name it, select the XP Pro OS and click the ―Import‖ button. This inserts the script into the LANDesk db.10.From the Management Console, open the Operating System Deployment tool and expand the My Templates section underProvisioning Templates.11.Right click on ―All my templates‖ and select New Template.12.Give the Template a name that represents what we are doing such as ―Scripted XP Install‖ and select ―Windows PE‖ for theBoot environment and ―Windows XP Pro‖ for the Target OS (This example is for XP Pro) and click OK.13.Right click the OS installation section and select ―Add Action‖.14.Give the action a name and select the ―Map/Unmap drive‖ action under the Type section.15.Select the ―Map a drive‖ action and enter in the UNC path to where the drivers are located, enter in the drive letter to be u sed,the user name to gain access to the share and the password variable ―%ldpassword%‖.16.Right click the OS installation section and select ―Add Action‖.17.Give the action a name and select the ―Copy File‖ action under the Type section.18.Enter in the Source path to the drivers including the mapped drive letter and then the Destination path where they should becopied to. Check to copy subdirectories assuming that the drivers are more than one folder deep.19.Right click the OS installation section and select ―Add Action‖.20.Give the action a name and select the ―Scripted Install‖ action under the Type section.21.Enter in the UNC path to the installation media ―WINNT32.EXE‖ file, the credentials to gain access and the passwordvariable ―%ldpassword%‖.22.Under the additional parameters, add ―/syspart:C:‖ and point to the installation script imported from an earlier step.Install the LANDesk Agent1.From the Management Console, open the Operating System Deployment tool and expand the My Templates section underProvisioning Templates.2.Right click on ―All my templates‖ and select New Template.3.Give the Template a name that represents what we are doing such as ―Install LANDesk Agent‖ and select ―Not applicable‖for the Boot environment and ―Windows XP Pro‖ for the Target OS (This example is for XP Pro) and click OK.4.Right click the System Configuration s ection and select ―Add Action‖.5.Give the action a name and select the ―Configure Agent‖ action under the Type section.e the drop down menu to specify which LANDesk agent to install, enter in credentials that will have access the passwordvariable ―%ldpassword%‖.Note: Additional actions can be performed such as Software Distribution, Join Domain, Patch System and Install Services. Grouping templates created and schedulingThe Template view displays the templates that are included in the current template (included templates are also known as Child templates). You can view the templates, and add templates to the current template. Once a template is included with a template, it is part of the parent template. If you change the included template in its original stand-alone form, it is changed in the parent template package, too.For this example, a template was create for each section to show that templates can include other templates and is easier to manage and use in the future provisioning tasks.1.From the Management Console, open the Operating System Deployment tool and expand the My Templates section underProvisioning Templates.2.Right click on ―All my templates‖ and select New Template.3.Give the Template a name that represents what we are doing such as ―FormatDrives-ScriptedXP-InstallAgent‖ and select―Win PE‖ for the Boot environment and ―Windows XP Pro‖ for the Target OS (This example is for XP Pro) and click OK.4.From the ―Includes‖ section and click on Include and add the templates created in previou s steps as seen below.5.Go to the ―Action List‖ section and notice that there are templates added to each section instead of the actions.6.Once this template that includes all the actions to be performed is scheduled or executed manually, a new template is createdand time-stamped and will show up as a locked template as seen in the screenshot below.Note: Once a master template is scheduled and you know this is how you want the template to run, the locked template should be the template scheduled to run on client devices. It is designed this way to be able to duplicate the same steps on all systems. Every time a master template is scheduled, a new locked template is created, so do not plan to use the master for all the machines to be provisioned.Provisioning HistoryThe History button lets you view a devices provisioning history by letting you check on the status of a particular task, determining how a particular machine was provisioned, or finding out which devices were provisioned with a particular template. When a system is provisioned, all the actions are recorded in the provisioning history.If you want to put a system back into a known state, you can replay the template that lets you return to that known state. If you want to replay a template, keep in mind that some actions are external to provisioning. Save any software distribution packages, agent configurations, and programs that you download and execute in conjunction with a template. Otherwise you won’t be able to rep lay them.To view a template/device provisioning history1.From the Management Console, open the Operating System Deployment tool and expand the My Templates or Public sectionunder Provisioning Templates.2.Double-click a template.3.In the left navigation pane, click History.4.Double click on the device and view the history of a specific machine.Note: You can also right click on a device in Scheduled tasks to view the provisioning history.Adding a bare metal deviceProvisioning lets you target and re-provision existing managed systems that appear in your LANDesk management solution or you can provision new hardware devices that have just arrived from the manufacturer or that have received a new hard drive.To do so, you enter the MAC address as a hardware identifier in the Identify devices dialog (or other unique identifying information such as the serial number, IPMI GUID or AMT GUID) to record the minimal information required by the automated provisioning agent (ldprovision) in the LANDesk core database.Management Console Steps:1.In Network View, open the Configuration folder.2.Right-click the Bare Metal Server folder, and click Add devices.3.Select MAC address in the Identifier type drop-down list.4.To add a single device, enter the MAC address in the Identifier box to the right and click Add device, or (to add multipledevices) type the location of a text file (CSV) which contains the identifier information in the text box (or click Browse to find the file), and click Import.5.Click OK to add the devices to the database.The n ewly added device shows up in the list of all devices, and is identified as having a ―Bare Metal‖ operating system type. You can also import a list of devices that have been saved to a CVS file if several new systems are arriving simultaneously.Provisioning RightsThe RBA rights for provisioning are divided into two settings: Configure Provisioning and Schedule Provisioning. The Configure right allows the user to edit templates. The Schedule right allows the user to schedule templates that already exist. Since a user who builds provisioning templates should test those templates, the Configure right requires the Schedule right. Companies may want to give the Schedule right to new, untrusted employees. Those employees would be able to schedule a task to provision a server, but the task will only do what the trusted employee (with the Configure right) defined for that template.ConclusionThis is a best practice guide specifically for unattended installations. This is one source of information to get a new or existing user of LANDesk started in the right direction with the Provisioning of devices.ReferencesAdditional resources can be found in the online help and under the Provisioning section in the LANDesk Community.AcronymsBKM – Best Known MethodPXE – Pre-Execution EnvironmentROM – Read Only MemoryBIOS – Basic Input/Output SystemWinPE – Windows Preinstallation EnvironmentLinuxPE – Linux Preinstallation EnvironmentOSD – Operating System DeploymentUNC – Universal Naming ConventionIPMI – Intelligent Platform Management InterfaceMAC address – Media Access Control addressAbout LANDesk SoftwareThe foundation for LANDesk’s leading IT management solutions was laid more than 20 years ago. And LANDesk has been growing and innovating the systems, security, service and process management spaces ever since. Our singular focus and our commitment to unde rstanding customers’ real business needs—and to delivering easy-to-use solutions for those needs—are just a few of the reasons we continue to grow and expand.LANDesk pioneered the desktop management category back in 1993. That same year, IDC named LANDesk the category leader. And LANDesk has continued to lead the systems configuration space: pioneering virtual IT technology in 1999, revolutionizing large-packet distribution with LANDesk® Targeted Multicast™ technology and LANDesk® Peer Download™ technology in 2001, and delivering secure systems management over the Internet and hardware-independent network access control capabilities with LANDesk® Management Gateway and LANDesk® Trusted Access™ Technology in 2005.In 2006, LANDesk added process management technologies to its product line and began integrating the systems, security and process management markets. LANDesk also extended into the consolidated service desk market with LANDesk® Service Desk, and was acquired by Avocent to operate as an independent division.Today, LANDesk continues to lead the convergence of the systems, security, process and service management markets. And our executives, engineers and other professionals work tirelessly to deliver leading solutions to markets around the globe.AuthorCraig MiddelstadtRevision 1.1December, 18 2007。

RTT使⽤问题总结1 ENV下不⽤将stm32fnxx_hal_msp.c拷贝到RTT⼯程⽂件夹下(也不⽤调⽤其中的⽚上外设函数如voidHAL_SPI_MspInit(SPI_HandleTypeDef* hspi)，听说KCONFIG⾃⼰会调⽤根据弱定义寻找；studio下根据⽂档说是需要；stm32_spi_init(drv_spi.c line81)-》HAL_SPI_Init(被spi_conifgure 调⽤drv_spi.c line387，代码在hal_spi.c line 310,⼜调⽤了 HAL_SPI_MspInit)-》 HAL_SPI_MspInit(hspi)-》在stm32f4xx_hal_spi.c中弱定义，在stm32f4xx_hal_msp.c 中根据cubumx⽣成，所以需要将cubumx⽣成的 HAL_SPI_MspInit拷贝到board.c下。

HAL_SPI_MspInit在stm32f4xx_hal_spi.c中弱定义；在由cubumx在stm32f4xx_hal_msp.c⽣成。

HAL_SPI_Init调⽤HAL_SPI_MspInitstm32_spi_init(）调⽤HAL_SPI_Init（）spi_configure调⽤stm32_spi_init(）spi_configure通过stm_spi_ops结构体被rt_spi_bus_register调⽤-》⼜被rt_hw_spi_bus_init(void)-》⼜被rt_hw_spi_init(void)调⽤-》通过INIT_BOARD_EXPORT(rt_hw_spi_init)调⽤进⾏初始化。

2 关于SPI配置，当设定最⼤速率后最终发现时钟频率降低2倍的原因，是因为RTT获取时钟源函数stm32_spi_init下的 SPI_APB_CLOCK不正确，没有正确反映外设挂在哪个总线下⾯；解决⽅法有2种：⽅法1 ：将struct rt_spi_configuration cfg 的cfg.max_hz*2并做好备注声明（适合共享给其它⼈应⽤的软件包）；⽅法2：将下⾯的通过宏定义修改正确，从⽽获得正确的参数时钟（分频值），这种⽅法适合代码⾃⽤（因为别⼈不⼀定⽤该SPI，且时钟源也不⼀定相同（不同系列的STM32));#if defined(SOC_SERIES_STM32F0) || defined(SOC_SERIES_STM32G0)SPI_APB_CLOCK = HAL_RCC_GetPCLK1Freq();#elseSPI_APB_CLOCK = HAL_RCC_GetPCLK2Freq();#endif3 外设的使⽤⼀定要注意打开board.h进⾏类似以下的声明#define BSP_USING_UART1#define BSP_UART1_TX_PIN "PA9"#define BSP_UART1_RX_PIN "PA10"4 ⾃⼰写的驱动⽼是说找不到头⽂件，尽管路径已经设置好了，原因时下⾯的宏没有打开#define PKG_USING_ADE7913#ifdef PKG_USING_ADE79135 studio下从HSI到HSE,将cubmx⽣成的SystemClock_Config 替换 drv_clk.c中的system_clock_config(target_freq)并将该函数的源代码屏蔽；同时在 STM32F4xx_HAL_CONF.H中修改HSE的值//先修改stm32f1xx_hal_conf.h中的 HSE_VALUE与实际的⼀致//然后在drv_clk.c中替换SystemClock_Configvoid clk_init(char *clk_source, int source_freq, int target_freq){//system_clock_config(target_freq);SystemClock_Config();}//最最后同时也修改board.h中的三个宏，尽管原来的HSI时钟配置也没有⽤到其进⾏计算，只是为了提⽰输出*-------------------------- CLOCK CONFIG BEGIN --------------------------*/#define BSP_CLOCK_SOURCE ("HSE")#define BSP_CLOCK_SOURCE_FREQ_MHZ ((int32_t)8)#define BSP_CLOCK_SYSTEM_FREQ_MHZ ((int32_t)72)/*-------------------------- CLOCK CONFIG END --------------------------*/6 studio下SPI的使⽤，按照board.h中所说即可，不⽤显⽰调⽤HAL_SPI_MspInit(&hspix)，有的地⽅⾃会调⽤7 对于多个线程共享互斥量时⼀定要注意：1 申请和释放要成对使⽤；2 如果有条件分⽀要么在各⾃分⽀中释放（适⽤于如果分⽀执⾏完需要较长时间。

ethereal汉化版用法目录1 Ethereal介绍 51.1 Ethereal为何物？ 51.1.1 Ethereal可以帮人们做什么？ 51.1.2 界面功能 51.1.3 实时的从不同网络介质抓取数据包 6 1.1.4 导入来自其它抓包工具的文件 61.1.5 为其它抓包工具导出文件 61.1.6 丰富的协议解码器 71.1.7 开放源代码软件 71.1.8 Ethereal不能做什么？ 71.2 Ethereal运行平台 71.2.1 Unix 71.2.2 Linux 81.2.3 Microsoft Windows 81.3 那里可以得到ethereal? 81.4 Ethereal的读法 91.5 Ethereal的历史 91.6 Ethereal的设计和维护 91.7 问题报告和获得帮助 91.7.1 Web网站 91.7.2 WIKI 101.7.3 FAQ 101.7.4 邮件列表 101.7.5 问题报告 101.7.6 liunx/unix平台崩溃报告 111.7.7 Windows平台崩溃报告 112 编译和安装ethereal 112.1 介绍 112.2 获得ethereal源代码和应用发布版本 12 2.3 UNIX平台编译ethereal之前准备工作 12 2.4 UNIX平台编译ethereal源代码 132.5 UNIX平台应用版本安装 132.5.1 RedHat 的RPMs方式安装 142.5.2 Debian的安装方式 142.6 解决UNIX下安装失败问题 142.7 Windows下源代码的编译 142.8 Windows下Ethereal安装 142.8.1 安装ethereal 142.8.2 升级ethereal 152.8.3 卸载ethereal 153 用户操作界面 153.1 介绍 153.2 启动ethereal 153.3 ethereal主界面 153.4 “The Menu”主菜单 163.4.1 “File”文件菜单 183.4.2 “Edit”编辑菜单 193.4.3 “View”视图菜单 213.4.4 “GO”跳转菜单 233.4.5 “Capture”抓包菜单 243.4.6 “Analyze”分析菜单 243.4.7 “Statistics”统计报表菜单 263.4.8 “Help”帮助菜单 273.5 “Main”常用工具栏 283.6 “Filter Toolbar”显示过滤器工具栏 303.7 “Packet List”数据包列表窗格 313.8 “Packet Details”数据包信息树窗格 313.9 “Packet Bytes”数据包字节窗格 323.10 “Statusbar”状态栏 324 网络数据包实时抓取 334.1 介绍 334.2 使用Ethereal前的准备工作 334.3 如何开始抓包？ 334.4 “Capture Interfaces”抓包网络接口窗口 344.5 “Capture Options”抓包选项窗口 354.5.1 “Capture”抓包常规框 354.5.2 “Capture File(s)”数据包文件框 364.5.3 “Stop Capture…”停止抓包框 374.5.4 “Display Options”显示选型框 384.5.5 “Name Resolution”名称解析框 384.5.6 “Buttons”按键 394.6 数据包文件和文件模式 394.7 “Link-layer header type”链接层数据头类型 40 4.8 抓包过滤器 404.9 抓包状态信息窗口 424.9.1 停止抓包 424.9.2 重新开始抓取 435 数据包文件导入、导出和打印 435.1 介绍 435.2 “Open”打开数据包文件 435.2.1 “Open Capture File”打开数据包文件窗口 44 5.2.2 支持导入文件格式 455.3 “Save As”存储数据包 455.3.1 输出文件格式 465.4 “Merging”合并数据包文件 475.5 “File Sets”文件系 485.6 “Exporting”导出文件 495.6.1 “Exporting as Plain Text File”导出无格式文件 495.6.2 “Export as PostScript File”导出PS格式文件 505.6.3 “Export as CSV(Comma Seperated Values)File”导出CSV(逗号分割)文件 50 5.6.4 “Export as PSML File”导出PSML格式文件 515.6.5 “Export as PDML File”导出PDML格式文件 515.6.6 “Export selected packet bytes”导出被选择数据包数据 525.7 “Printing”打印数据包 535.8 “Packet Range”数据包范围窗格 556 数据包分析 556.1 如何查看数据包 556.2 显示过滤器 606.3 如何书写显示过滤器表达式 616.3.1 显示过滤器字段 616.3.2 比较操作的数据类型和操作符 626.3.3 组合表达式 626.3.4 显示过滤器常见误解 636.4 “Filter Expression”过滤器表达式窗口 646.5 定义和存储过滤器 656.6 搜索数据包 676.6.1 “Find Packet”搜索数据包窗口 676.6.2 “Find Next”寻找下一个 686.6.3 “Find Previous”寻找上一个 686.7 “GO”跳转 686.7.1 “Go Back”后退 686.7.2 “Go Forward”向前 686.7.3 “Go to Packet”跳转到 686.7.4 “Go to Corresponding Packet”跳转到相关数据包 696.7.5 “Go to First Packet”跳到第一个数据包 696.7.6 “Go to Last Packet”跳到最后一个数据包 696.8 标记数据包 696.9 时间显示格式和时间基准点 706.9.1 时间显示格式 706.9.2 时间基准点 707 高级工具 727.1 介绍 727.2 “Following TCP streams”跟踪TCP数据流 727.2.1 TCP数据流跟踪窗口 737.3 Time Stamps时间标记 747.3.1 Ethereal内部时间格式 747.3.2 数据包文件时间格式 747.3.3 时间正确性 747.4 时区问题 757.4.1 什么是时区？ 757.4.2 为你的计算机设置正确时间 757.4.3 Ethereal和时区 767.5 数据包重组 767.5.1 什么是数据包重组？ 767.5.2 Ethereal如何实现包重组 767.6 名称解析 777.6.1 以太网名称解析(MAC层) 777.6.2 IP名称解析（网络层） 787.6.3 IPX名称解析（网络层） 787.6.4 TCP/UDP端口名称解析（传输层） 787.7 确保数据完整性 787.7.1 Ethereal核对概要 797.7.2 硬件里的概要计算和确认 798 统计 798.1 介绍 798.2 “Summary”统计窗口 808.3 “Protocol Hierrrchy”协议层次统计窗口 81 8.4 “Endpoint”终端统计 828.4.1 Endpoint终端是什么？ 828.4.2 终端统计窗口 838.5 会话统计Conversations 838.5.1 什么是会话 838.5.2 会话窗口 838.6 IO曲线图窗口 858.7 服务响应时间统计 869 Ethereal客户配置 879.1 介绍 879.2 定义数据包颜色 879.3 控制协议解析器 899.3.1 “Enabled Protocols”协议解析开关窗口 89 9.3.2 用户配置解码 909.3.3 查看定义的解码方式 919.4 参数选择 921 Ethereal介绍1.1 Ethereal为何物？Ethereal是开源网络数据包分析软件。

第六章 负载均衡及服务器集群（lvs）作者:田逸(sery@)在互连网应用技术里,负载均衡一直是热门话题,本书讨论的负载均衡技术,包括但不限于负 载均衡本身。

使用负载均衡技术主要的目的包括如下几点： ◆ 系统高可用性。

组成系统的某些设备或部件失效，并不会影响正常的服务。

◆ 系统可扩展性。

用户的增加，引起访问数乃至流量的增加，这种情形下，需要对系统进 行扩容，以应对这种快速增长。

对于提供高可用服务的互联网网站，其对可扩展的基本 要求就是在保持系统服务不终止的情况下， 透明的扩充容量， 即用户不知道扩容的存在， 或者说是扩容不对现有的服务产生任何负面作用。

这些扩展主要包括：带宽扩展、服务 器扩展、存储容量扩展、数据库扩展等，当然也包括主机增加内存等方面的扩展。

◆ 负载均衡能力。

一个应用或服务由数个物理服务器提供,并且每个物理服务器运行的应用 或服务是相同的,我们可以让用户的访问通过某种控制策略,把负载分摊到不同的物理服 务器,从而保持每个物理服务器有比较合理的负载。

当整个系统的负载趋于饱和时， 通过 增加物理服务器和扩充物理带宽来解决这个麻烦。

增加物理服务器以后，系统的负载情 况将重新在所有集群的物理服务器之间按照指定的算法重新达到新的均衡。

一个完整的负载均衡项目，一般由虚拟服务器、故障隔离及失败切换 3 个功能框架所组成。

虚拟服务器是负载均衡体系的基本架构，它分两层结构：转发器（Director）和真实服务器。

图 6-1 为虚拟服务器的结构示意。

图 6-1 虚拟服务器结构为什么称虚拟服务器？因为从用户的角度看来， 似乎只是一个服务器在提供服务。

虚拟服务 器最主要的功能是提供包转发和负载均衡，这个功能可以通过撰写 ipvsadm 脚本具体实现。

虚拟服务器项目由章文嵩博士所贡献，目前已被添加到各种 linux 发行版的内核。

故障隔离指虚拟服务器中的某个真实服务器（或某几个真实服务器）失效或发生故障，系统 将自动把失效的服务器从转发队列中清理出去，从而保证用户访问的正确性；另一方面，当 实效的服务器被修复以后，系统再自动地把它加入转发队列。

砖引玉吧，希望大家不断的补充。

问问题的朋友不要在这里问，为了方便查询，这里不回答。

希望大家一起来维护，有要更新的，请跟帖，我会及时补充上。

跟贴的时候，请写名属于那一类，详细说明功能。

还要麻烦diag也来维护。

硬件系统：1、如何查看cup的状态？作者:南非蜘蛛# psrinfo -v# mpstat 可以列出多cpu负载的状态2、如何查看内存？作者:南非蜘蛛# prtconf | grep 'Memory' 可以查看内存的多少.# /usr/platform/sun4u/sbin/prtdiag3、如何动态添加swap分区？# $su －root ----- 成为超级用户# mkfile 100m /home/swapfile ----- 创建100m的Swap文件# /usr/sbin/swap －a /path/filename ----- 激活Swap文件# /usr/sbin/swap －l ----- 验证swap文件# /usr/sbin/swap －d /path/filename ----- 取消swap文件# rm -rf /home/swapfile ----- 删除swap文件4、如何查看当前网卡是以何种速率起来的？作者:南非蜘蛛# dmesg |grep Link5、如何调整x-window的分辨率和刷新频率？字符界面登陆，运行：#/kdmconfig6、如何使用光、软驱？一般情况下用：# /etc/init.d/volmgt start# volcheck以上方法不行，用：# /etc/init.d/volmgt stop# mount -F hsfs -o ro /dev/dsk/c0t6d0s0 /cdrom --挂接光驱# mount -F pcfs /dev/diskette0 /floppy --挂接软驱solaris定义系统磁盘文件系统说明：ufs – UNIX文件系统。

目录使用OpenSER构建电话通信系统 (1)第一章：SIP介绍（Introduction to SIP） (1)第二章：SIP快速路由器（The SIP Express Router） (28)第三章：OpenSER安装（OpenSER Installation） (42)第四章：OpenSER标准配置（OpenSER Standard Configuration） (58)第五章：用MySQL添加认证（Adding Authentication with MySQL） (85)第六章：使用SerMyAdmin构建用户入口 (121)第七章：与PSTN的连通（Connectivity to the PSTN） (138)第八章：通话前转和语音邮件（call forward and voice mail） (177)使用OpenSER构建电话通信系统Building Telephony Systems with OpenSER第一章：SIP介绍（Introduction to SIP）会话初始化协议是互联网工程任务组（IETF）制定的协议标准，在多个RFC （Request for Comments）文档中被进行了描述说明。

RFC3261是最近的一个RFC，一般称它为SIP版本2。

SIP是一个应用层的协议，用来建立，修改，终止会话（sessions）或是多媒体通话（multimedia calls）。

这些会话可以会议（conferences），e-learning，网络电话和一些相似的应用。

它是同HTTP协议相类似的文本协议并且被设计用来发起，保持，关闭用户之间的交互会话。

目前SIP已经是VoIP领域被广泛使用的协议之一了，市场上几乎每一台IP电话都会支持它。

本章结束的时候你将能够：●描述SIP是什么●描述SIP是干什么的●描述SIP的框架●解释SIP主要部件的意义●理解并比较主要SIP消息●描述INVITE和REGISTER请求消息头部的处理过程在建立和关闭多媒体通话的过程中，SIP协议支持五种要素。

RDP:A Result Delivery Protocol for Mobile ComputingMarkus Endler,Dilma M.Silva and Kunio OkudaDepartment of Computer ScienceUniversity of S˜a o Paulo,Brazilendler,dilma,kunio@p.brAbstractNowadays several information retrieval services are be-ing offered to mobile clients.Many of such services are im-plemented by groups of distributed servers and sometimesemploy time-consuming data location and retrieval proto-cols among the servers.Moreover,many network appli-cations have strong reliability requirements.This meansthat client-server communication in services for mobilecomputing must also be reliable despite the intrinsic non-predictability related to mobile computing.In this paper we present a client-server protocol whichimplements reliable delivery of messages to mobile hosts.Reliability here means that for every request from a mo-bile client to a network service,eventually it will receivethe result,despite its periods of inactivity and any numberof migrations.This protocol is suitable for network servicesbased on request-reply style of communication(e.g.RPC)and with long request processing times,i.e.where there ishigh probability that a client at a mobile host migrates toanother cell while waiting for the reply.The main advantage of our protocol is that the locationof the proxy used to forward messages to a mobile host isnot static(as in Mobile IP),by which it facilitates dynamicglobal load balancing within the set of Mobile Support Sta-tions.1.IntroductionWith the ongoing improvement and spread of cellulartelephony technology,more and more computer networkservices will be supporting wireless communication.Soon,it will be possible to access many sorts of information basesfrom lightweight,inexpensive and hand-held terminals orPDAs,regardless of their current location.Also,many ofthese information bases will be fed with data sent by thesemobile devices,which may range from frequent updatesinteractions and processing within the TIS network.In order to implement efficiently the operations offered by the system to mobile users(such as query,update,sub-scribe1,and multicast2)we are designing and implementing a suite of protocols[7]that handle different aspects of the operations,such as user mobility,data location,data repli-cation,TIS interaction,etc.We hope that the model and the protocols are generic enough to be easily adaptable to a variety of applications,ranging from support systems for strategical actions to electronic mail systems for portable computers.In this paper we focus our attention on a connectionless communication protocol for mobile clients named Result Delivery Protocol(RDP).In our project,this protocol is used for the query and subscription operations mentioned before.The remainder of this paper is organized as follows:In section2we define the system model and the underlying assumptions.In section3we describe the Result Deliv-ery Protocol,focusing on how location updates of migrat-ing clients and retransmissions are handled by the protocol. We then compare our protcol with related work in section 4.Finally,in section5we give informal arguments about its correctness and the incurred overhead and draw some conclusions.2.System Model and AssumptionsThe model of the system consists of two types of ma-chines,the static hosts and the mobile hosts().Static hosts are connected to each other through a static and reli-able network.Among the static hosts,some also serve as Mobile Sup-port Stations()for the mobile hosts and are assumed not to fail.Each defines a geographic region(cell) in which it is able to communicate with the set of mobile hosts currently located in the cell.The information about the s within a cell is maintained at each in a data structure local1The user specifies an entity and a threshold on any of its attribute val-ues,and the system will notify the user about related changes in the entity.2The user provides its identification,the identification of a group of users(previously configured)and a message to be sent to the group.sends a join message to the in charge for the cell it is currently in,which then becomes the currently responsible for the(respMss).A leaves the system by sending a leave message to its respMss.Mobile hosts are able to move from one cell to an-other.Whenever a enters a new cell it sends a greet(oldMss)message to the responsible for the target cell,where oldMss is the identity of the re-sponsible for the cell which the is leaving.With this information the of the new cell is able to initiate a Hand-off protocol with the previous(see Section3.2).This greet message is also sent by the when it becomes active again within the same cell where it has been before become inactive.In this particular case,however,the will not initiate a Hand-off protocol,since the previous mentioned in message greet is itself.Actually,in this model we abstract from the details of how a learns that it is entering or leaving a cell,assum-ing that this can be achieved in different ways according to the wireless technology in use.Figure1shows a system with three s andfive s (in the corresponding cells or migrating)and where mobile host is issuing a request to server from one cell,but may pick up the server’s reply while visiting another cell.The main assumptions of the model are the following: munication among the s is reliable and mes-sage delivery is in causal order;2.All are reliable and do not fail;3.At any time,each active is associated with exactlyone(respMss).4.If a is active it must send an Ack to all messagesreceived from its respMss,and while it is inactive itmust not reply to any message.When a migrates between cells it may be considered inactive by both the ()or the new Mss()during the period of time of the Hand-off.5.A is able to detect if a message from its respMssis a new one or if it is a retransmission.6.A only leaves the system if it has acknowledgedall messages received by its respMss.3.Result Delivery ProtocolIn the remainder of this paper we present and analyze a protocol which guarantees reliable delivery of reply mes-sages from a server in the network to a mobile client.This protocol,which we called Result Delivery Protocol,is suit-able for network services based on a request-reply style of interaction(e.g.RPC)and with long request processing time.For such services,it is likely that the client(on the mobile host)migrates to another cell while waiting for the result of the request.The protocol can be used with a wide range of existing network services since from the perspec-tive of the server,service access is identical to the one by a static client.Although the presentation of the protocol is focussed on a request-reply style of interaction,like operation query of the traffic information service(Section1),it can be used as well for asynchronous notifications of events to mobile clients.Thus,the RDP may as well be used for implement-ing the operation subscribe(Section1),by which a mobile client is informed of any major change in the traffic situa-tion.The RDP protocol is based on the indirect model for client-server interactions proposed by Badrinath et al.[2]. In this model the mobile support stations act as represen-tatives for all the mobile hosts within their cell,hold part of the’s state,and do the translation between the wired and the wireless communication.3.1.Outline of the ProtocolThe Result Delivery Protocol(RDP)is based on the no-tion of a proxy for requests(or simply proxy).A proxy is created on behalf of a that wishes to interact with servers within the wired network.It is created at the responsible for the’s current cell(respMss)whenever the initiates a new series of service requests.The main purpose of the proxy is to provide afixed location for the re-ception of server replies,to keep track of pending requests, store the request’s results,and to forward the results to the responsible for the cell in which the is currently located.The proxy object exists only until all result for-wards are acknowledged by the corresponding.Then,at a later moment,the same may cause the creation ofa new proxy at the same or a different,depending on whether it has or not migrated.However,at any time each is associated with at most one proxy.In order to decide to which to forward the result of a request,each proxy holds a variable called currentLoc,which is updated with the address of the current respMss of the corresponding whenever it migrates.A proxy alsoholds a requestList containing identifiers of all pend-ing requests issued by the.For being able to update currentLoc at every migra-tion,each has one proxy reference(or simply pRef) associated to it,which is hold by its respMss.As the namesuggests,a pRef contains a reference(the i.e.address ofthe and a proxyID)to the current proxy associated with the.However,when a does not have a proxy(i.e.when it has no pending requests)pRef holds a null ad-dress.A pRef also contains aflag called Ready to Kill pRef(RKpR),which signals whether the proxy has forwarded theresult of its last pending request(see section3.3for more details).Each time a receives a new request from one of its local s it checks the corresponding pRef.If it hasan null address,a new proxy is created locally on behalf of and updates pRef with its own address and the proxy’s objectID.Otherwise,Mss forwards the request tothe proxy whose address is mentioned in pRef.When a migrates from to pRef ishanded over through the Hand-off protocol(see Section3.2) to as part of’s state.After completion of the Hand-off for a,’s new location is updated at the proxy.This is done by having send a special mes-sage(update currentLoc)to the proxy.This message is also sent when a respMss receives a greet message from the announcing its switch from the inactive to the ac-tive state.At the proxy,the arrival of the update cur-rentLoc message causes the variable currentLoc to be updated and any non-acknowledged results from pend-ing requests to be re-sent to the new location.When the result of any of s pending requests(say,re-quest R)arrives at a proxy(located at)it is forwarded by to the address mentioned in currentLoc(i.e. respMss)and then delivered to through wireless com-munication.In normal conditions,i.e.when a is active and staysin its cell for a sufficient long period of time,the arrival ofR’s result is acknowledged by the through a Ack mes-sage,which is forwarded by to.Once it has arrived,the proxy marks that request R has been completed, removes it from the requestList,and possibly sends an acknowledgment to the server,depending on the particular application-level client-server protocol being used.If respMss is unable to reach,because it is migrat-ing or is in inactive state,or simply because wireless com-munication failed,the respMss does not attempt any new forwarding of the result.Instead,it is the proxy that will re-sent the result as soon as it receives the next update of ’s address.At each,higher priority is given to forwarding Ack messages(from s to)than to engaging in any new Hand-off transactions.This avoids that results already ac-knowledged by a are re-sent to the new cell.However, as soon as respMss receives a request(from another) to transfer’s state,as part of the Hand-off protocol,it will ignore all future Ack messages from this.From the viewpoint of the proxy,until it does not receive an Ack message informing that R’s result has been indeed received by the,it keeps re-sending the result to every from which its gets a update currentLoc mes-sage.Notice that this guarantees that every result from a request will eventually reach its destination(the),pro-vided that the does not leave the system with a pending request.The price to pay for this reliability is that eventu-ally a result will be sent more than once to a.3.2.Hand-off ProtocolThe Hand-off protocol is executed between a and whenever a switches cells,and aims at transfer-ring all of’s relevant state to.It works as follows:A entering a new cell registers itself with the cor-responding Mobile Service Station(i.e.)by sending it a greet message containing the identification of its pre-vious respMss.After having announced itself to,a must not reply to any message from any other than.When receiving the greet message,sendsa dereg message,asking it to de-register and send back’s proxy reference(pRef).When re-ceives dereg Mh,it replies to with a deregAck message containing’s pRef,and then removes from its localMhs list and updates’s new location with its proxy,by send-ing the update currLoc message to the proxy,whose address is contained in pRef.The greet message is also sent by a when it be-comes active again within the same cell where it has been before become inactive.In this case,however,message greet carries the identification of s current respMss, and hence no Hand-off is initiated.3.3.The Proxy Life-cycleAlthough every always has at most one proxy that forwards results to it,the location of the proxies in the static network may change over time,by which the protocol facili-tates dynamic global load balancing within the set of s.As mentioned earlier,a proxy is created whenever a issues a new request and no proxy is yet available,i.e.when address in’s pRef is empty.After creation,a proxy is capable of handling several concurrent requests from its .When a proxy(hosted at)forwards the result of the last pending request(say,)to a respMss,flag del-pRef is set to and is piggy-backed on this result mes-sage sent to a’s respMss.It means that if this message is received by the,then the proxy can be deleted.When the respMss receives a result message with del-pRef,it setsflag RKpR true at’s pRef,mean-ing that respMss will confirm the removal of the proxy(and erase proxy’s address in pRef’s)as soon as it receives an Ack from that is not preceded by any new request.If this is the case,respMss sends message Ack withflag del-proxy piggy-backed on it to,by which this one knows that the proxy can in fact be deleted.How-ever,if in the meantime,a new request from arrives at respMss,flag RKpR is re-set to and Ack message is sent with del-proxy,meaning that the old proxy will also be used for this new request.Figure2shows the proxy and pRef objects,and theflags used to control the existence of the proxy.Thus,the removal of the proxy is confirmed by respMss only if the following condition holds:RKpR and for all of’s requests the corresponding Ack has been received.Notice that since will always use respMss as the gateway for new requests,it will never happen that a new request is sent to a which is not hosting a’s proxy.3.4.ExamplesIn this section we present two examples to illustrate how RDP works.Figure3shows a scenario where a mobile host Mh issues a single request to a server at,then migrates toand later to.Assuming that this is’sfirst request,its pRef will contain no address.Hence a new proxy is created at with its variable currentLoc (abbreviated by currL)set to and also the address in pRef is set to.Now each time the migrates(and after the Hand-off protocol is completed)the new sends an update currL message to the proxy in order to update its variable currL.MhrespMssMss pupdate currLupdate currLforward result forward resultserverMss Mss p oproxy MhrequestcurrL:=ppRef:=(Mssp)pRefcurrL:=oresultcurrL:=n?Mss nAckAck Hand-offHand-off+greetgreet++dereg+pRefdel-pRefdel-pRefdel-proxyderegAckWhen the response of the request (result )arrives atthe proxy,forwards it to the Mss metioned in currL ,even if in the meantime has migrated,as suggested by the question mark in the figure.Piggy-backed on the re-sult message goes del-pRef,because proxy’s requestList has a single entry.Because Mh has mean-while migrated to another cell,the proxy does not receivean Ack from,hence will repeat the forwarding every time its variable currL is updated,until it finally receives an Ack from the Mh .When receives the result with del-pRef ,it sets the flag RKpR at ’s pRef ,forwardsresult to Mh and waits for an Ack from.As soon as this message arrives,and since still RKpR ,erases the address at ’s pRef and also sends message Ack piggy-backed with flag del-proxy to .Finally,when this message arrives at the proxy is deleted.Figure 4depicts a scenario where a Mh issues several requests through its proxy,showing when the proxy is actu-ally deleted.In this scenario,the mobile host Mh first issues requestA at (creating a new proxy),and then mi-grates to Mss .Thus,initially the proxy’s requestListcontains only requestA and when resultA arrives fromthe server,forwards resultA with del-pRef to .When this message arrives,sets flag RKpR =true at ’s pRef ,and forwards resultA to Mh .However,since Mh issues a new requestB before send-ing an Ack for resultA (AckA )flag RKpR is set to false.Since now Mss receives AckA when RKpR,it leaves pRef ’s address unchanged.After receiving requestB followed by AckA ,the proxy’s requestList ends up holding only requestB ,and resultB is forwarded to .Assume that meanwhile a new requestC arrives at the proxy,causing its requestList to hold both requestB and requestC .When AckB is received by the proxy,and resultC is received and forwarded,requestB can be removed from requestList ,leaving only the single pending requestC .In this particular case,the proxy does not forward again resultB (which has already been sent),but sends a spe-cial message containing only del-pRef to ,where it causes flag RKpR at ’s pRef to be set to .Finally,when AckC arrives from ,pRef ’s address isset to null,and message AckC with del-proxyisAresultCAck BAck AresultAresultBresultBresultCrequestC resultA+requestBresultA Ack BAckCrequestBrequestCAck +AckC resultBresultCrequestBrequestCupdate currLMssrequestAMhrequestAproxy serverMsspHand-offdel-pRefdel-pRefdel-proxysent to proxy,which causes its deletion.This means that at the next time issues a new request,a new proxy will be created at its current respMss .However,suppose that the last del-pRef message hadarrived at Mss after AckC .Since RKpR,pRef would be left unchanged and AckC would be sent to with del-proxy ,avoiding the removal of the proxy.4.Related WorkIn our work,we adopt the indirect model for client-server interactions originally proposed by Badrinath et al.[2]and now adopted also in many other works [14,3,8].In this model mobility is made explicit to all protocol layers (up to the application layer)and the s serve as static interme-diates for any communication between the mobile clients and the servers executing on the pared to other approaches that make mobility explicit only to the protocol layers up to the network layer (e.g.Mobile IP and its optimizations [10]),the indirect model has as its main advantage the possibility to build mobility-aware higher-level protocols which use locality information to dynami-cally adapt themselves to variant transmission and/or net-work access conditions,such as communication bandwidth of wireless media,closest server,etc.Moreover,this model has the advantage of allowing the s to perform trans-lations between the wired and wireless medium,and also to store application-specific data related to the state of the‘local’s.Based on the indirect model,Bakre [3]proposes an in-direct TCP protocol (I-TCP)and protocols at higher layers,all of which take mobility into account.In his approachthe fixed host only ‘sees’an image of its peer,which is actually stored at its respMss and is transferred to otherwhen a moves between cells.However,since during a Hand-Off the wireless component of I-TCP sim-ply resets congestion-related parameters,I-TCP cannot rely on transport-layer acknowledgments and defers this respon-sibility to higher protocol layers.Moreover,the fixed host(the server)must be informed that a new is now hold-ing ’s image.Although our protocol is not aimed for connection-oriented services,and hence does not require maintaining the status of a connection,it proposes a solu-tion to minimize the disruption caused by the Hand-off.Although RDP is not a generic network protocol (since it is suited only for connectionless request-reply communica-tion,rather than for generic datagram delivery),it is useful to compare it with Mobile IP due to some common char-acteristics.In both protocols messages (or datagrams)are delivered to mobile hosts via intermediate elements.In Mo-bile IP they are called home and foreign agent and in RDP these are the proxy and the respMss .In both protocols,thecurrentlocation (in Mobile IP terminology,care-of ad-dress )is stored at the proxy and updated whenever the registers at a new .The main differences between the protocols are as fol-lows:In Mobile IP the home agent is fixed rather than dy-namic,making dynamic load balancing impossible.In RDP the proxy remains at a same location only while there are some pending requests,and as soon as all results of pend-ing requests have been delivered successfully to the corre-sponding ,the proxy removes itself.Thus,in RDP the proxy must keep track of the pending requests,meaning thatall new requests must be forwarded to thehosting the proxy ,which is not the case in Mobile IP.Another conse-quence of the proxy ’s dynamic address is that the proxy ref-erence (pRef)has to be handed over betweens at every migration.Since in Mobile IP the address of home agent isstatic,it can be included byinto each request.However,Mobile IP does not guarantee reliable data de-livery to the s.For example,IP datagrams may be lost while a new care-of address change is on its way to the home agent,or during the periods of inactivity of the mo-bile host.In fact,Mobile IP delegates the task of detect-ing and re-transmitting lost datagrams to upper network lay-ers,such as TCP.However,it has been shown that conven-tional transport-level protocols without mobility-awareness present bad performance when used in a wireless environ-ment[4].In RDP,on the other hand,Hand-Off is tightly integrated with the message delivery,ensuring that no mes-sages(i.e.request results)are lost despite migration or inactivity.Many other works have investigated the issue of dis-connected data access.In Project Dataman,from Rutgers, Imielinski and Badrinath[9]proposed several query and up-date strategies for distributed information services that store frequently modified data,such as the geographic location of individual mobile hosts.Project Rover[11],from M.I.T.,is a well-known dis-tributed object development environment for disconnected operation.It provides mobile computing support based on two concepts:Queued Remote Procedure Calls(QRPC) and Relocable Dynamic Objects(RDOs).In QRPC(asyn-chronous RPC)the actual sending of the RPC request is de-coupled from the QRPC invocation and is performed as soon as the has established a good communication link with a base station.A RDO is an object encapsulating both code and data that can execute either at the client or the server.In some sense,QRPC and RDP perform comple-mentary tasks.While thefirst guarantees reliable sending of requests,RDP guarantees reliable result delivery.Pitoura et al.[12]describe a general architecture of an information system for mobile environment,and in[13] propose support for transactions management for wireless environments.Although recently much attention has been given to the problems of database transaction management [6]with disconnection requirements,this issue is not ad-dressed by our work.In Project Wireless-View[15](U.Illinois-Chicago)sev-eral data allocation schemes are studied and specific cost models for access to continuously changing databases from clients at mobile hosts were proposed.Bayou[5](Xerox)is a weakly consistent storage system designed for a mobile computing environment that supports the development of a variety of collaborative applications, such as shared calendars,mail,databases,etc.Unlike our system model,Bayou treats mobile units as peers in a peer-to-peer model,where a mobile host may be both a Bayou client and server.In Bayou,collections of data items are fully replicated at a group of Bayou servers, and clients can read or write any copy residing on any server with which they are able to communicate.The main contri-butions of this system are its mechanisms for dependency checks and merge procedures,necessary for maintaining high availability of Bayou system with weak replica con-sistency.5.Protocol Analysis and ConclusionThe protocol presented in this paper guarantees delivery (of the result)with at least-one semantics,since the proxy keeps re-transmitting the result until an Ack message ar-rives,signaling that the has indeed received the re-sponse.However,a that becomes inactive right after reception of the result message(but does not send an Ack message)will receive this message again when it be-comes active again,either in the previous or in a new cell.If the already sent an Ack to its respMss and if wired communication guarantees delivery of messages in causal order,then the protocol ensures delivery of messages with exactly once semantics.This is because eachis supposed to handle Ack forwards with highest priority, and therefore the following sequence of causal dependen-cies among events(where denotes the sending of message from server)always holds:send(Ack)@Mss send(Ack+del-proxy)@Mss send(update currL)@Mss.Hence,the proxy will re-ceive the Ack message(forwarded by)before the message update currL,from,and will thus re-move the proxy instead of re-transmitting result.In any case,delivery of redundant messages is not a ma-jor problem,since it can be assumed that the is able to identify duplicated messages.If the wireless communication is reliable,re-transmissions of the result with the Result Delivery Protocol(RDP)occur only if the mean time period a spends in a cell is less than,where and are the average transmission times for the wired and wireless communication,respectively. This is unlikely to be the case for current mobile support systems where the diameter of the cells is of reasonable size,e.g.some kilometers.The major advantage is that,except for the proxy ref-erence,neither result forwarding pointers nor other residue (e.g.copies of the result message)need to be kept at the,i.e.the can discard the result message after a single attempt to forward it to the local3.The overhead of this protocol is limited to the follow-ing extra messages:(1)one update currL whenever the mobile host migrates or becomes active again;and(2)one extra Ack message sent from respMss to the proxy when-ever acknowledges the receipt of result.Besides,every request from the mobile host to an application server has to pass through the proxy,so that the proxy can hold it as pending.Our work extends the indirect model of Badrinath et al.[2]in the sense that the proxy represents yet another communication mediator between the mobile client and the server.The main advantage of using a proxy is that from the server’s point of view,the service is being requested from a fixed client(i.e.the proxy),which transparently handles all the mobility of the client it pared with sim-ilar approaches[3,1]our protocol aims at minimizing the transfer of a’s state between the old and new dur-ing Hand-off,because most of the data related to the request (e.g.the result)is kept at the proxy.The Result Delivery Protocol is being implemented as a prototype system in the scope of the SIDAM Project.In this prototype,we are simulating host mobility through ran-dom communication between distributed processes(repre-senting s,and servers)within a Linux network. Using this prototype,we will test this protocol concerning its efficiency with respect to several patterns of mobility, queries and subscriptions.At a future step,we intend to re-implement it in a network with real wireless communication support.The main advantage of the RDP protocol is that although at each moment only a single is responsible for re-transmitting the request results for a given,the proto-col facilitates dynamic global load balancing within the set of s.Moreover,the protocol guarantees that eventually every result will be delivered to the requesting despite any number of migrations and periods of inactivity. AcknowledgmentsWe gratefully acknowledge Ricardo da Rocha and our colleagues from project SIDAM for their valuable com-ments and suggestions.Project SIDAM is being supported by FAPESP(Grant no.98/06138-2).References[1]Arup Acharya and B.R.Badrinath.Delivering multi-cast messages in networks with mobile hosts.In13th International Conference on Distributed Computing Systems,pages292–299,Pittsburgh,US,May1993.[2]B.R.Badrinath, A.Bakre,T.Imielinski,andR.Marantz.Handling Mobile Clients:A Case for In-direct Interaction.In Proc.4th Workstation Operating Systems,October1993.[3]A.Bakre.Design and Implementation of Indirect Pro-tocols for Mobile Wireless Environments.PhD thesis, Rutgers University,October1996.[4]S.Biaz and N.H.Vaidya.Tolerating visitor locationregister failures in mobile environments.In Seven-teenth IEEE Symposium on Reliable Distributed Sys-tems(SRDS’98),pages109–117,Washington-Brus-sels-Tokyo,October1998.IEEE.[5]A.Demers,K.Petersen,M.Spreitzer, D.Terry,M.Theimer,and B.Welch.The Bayou Architecture: Support for Data Sharing Among Mobile Users.In Workshop on Mobile Computing Systems and Appli-cations,Santa Cruz,CA,U.S.,94.[6]M.H.Dunham and V.Kumar.Impact of Mobil-ity on Transaction Management.In Proc.of Mo-biDE/Mobicom99Workshop,Seattle,WA,pages14–21.ACM,August1999.[7]M.Endler.A protocol for atomic multicast amongmobile hosts.In Dial M Workshop/Mobicom’99,Sea-tle(USA),pages56–63.ACM,August1999.[8]M.Haar,R.Cunningham,and V.Cahill.Supportingcorba applications in a mobile environment.In Proc.of MobiCom99,Settle,WA,pages36–47.ACM,Au-gust1999.[9]T.Imielinski and B.R.Badrinath.Querying in highlymobile distributed environments.In Proc.of the18th VLDB Conference,1992.[10]David B.Johnson and David A.Maltz.Protocols foradaptive wireless and mobile networking.IEEE Per-sonal Comunications,3(1),February1996.[11]A.D.Joseph,J.A.Tauber,and M.F.Kaashoek.MobileComputing with the Rover Toolkit.IEEE Transactions on Computers,February1997.[12]E.Pintoura and B.Bhargava.Building informationsystems for mobile environments.In Proc.3rd Inter-national Conference on Information and Knowledge Management,pages371–378,1994.[13]E.Pintoura and B.Bhargava.Revising transactionconcepts for mobile computing.In Proc.IEEE Work-shop on Mobile Computing Systems and Applications, pages164–168,1994.[14]E.A.Brewer R.H.Katz.The Case for Wireless Over-lay Networks.In Proc.of the SPIE Conference on Multimedia and Networking,(MMCM’96),San Jose, CA,January1996.[15]O.Wolfson Y.Huang.Allocation in DistributedDatabases and Mobile Computers.IEEE Transactions on Parallel and Distributed Systems,9(4),April1998.。