Example: barber

Ticket Server Performance Evaluation Using a Hybrid ...

Ticket Server Performance Evaluation Using a Hybrid Simulation ApproachCory BeardVictor FrostUniversity of Missouri-Kansas CityUniversity of Network management, Ticket servers, per-formance. Abstract: A Ticket Server architecture was proposed in[1] and [2] to issue tickets to ensure access tocommunications resources in crisis situations. End usersinteract directly with servers Using intelligent agents thatuse an agent communication language. Here a hybridsimulation approach is used to assess Ticket serverperformance requirements and network administrativeoverhead.

queueing analysis. This methodology was then used to simulate a hurricane event and an office building bombing event similar to the Alfred P. Murrah Federal Building

Tags:

  Queueing

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Advertisement

Transcription of Ticket Server Performance Evaluation Using a Hybrid ...

1 Ticket Server Performance Evaluation Using a Hybrid Simulation ApproachCory BeardVictor FrostUniversity of Missouri-Kansas CityUniversity of Network management, Ticket servers, per-formance. Abstract: A Ticket Server architecture was proposed in[1] and [2] to issue tickets to ensure access tocommunications resources in crisis situations. End usersinteract directly with servers Using intelligent agents thatuse an agent communication language. Here a hybridsimulation approach is used to assess Ticket serverperformance requirements and network administrativeoverhead.

2 The negotiation interaction between users andservers is implemented in a prototype. Network and ticketserver Performance are modeled Using prototype resultscombined with analytical techniques for networks ofqueues. For two scenarios to simulate a hurricane eventand an office building bombing event, Ticket serverperformance requirements, network overhead, andconnection setup delays were not found to be broadband networks are designed to integrateall types of multimedia traffic. More importantly,however, they are designed to integrate and support theactivities of all types of users.

3 As networks become moreand more useful to society, new types of users and userapplications user type of particular interest is the NationalSecurity/Emergency Preparedness (NS/EP) user. For sucha user, prioritized access to network resources is vital,especially in times of response to natural or man-madedisasters. This is because network facilities are commonlydamaged and network demand frequently exceeds availableresources [3].In [1], a Ticket Server architecture was proposed tomanage priority network activities. This architecture isillustrated in Figure 1.

4 Users interact directly withregionally distributed Ticket servers to request importancetickets that can be presented to generic network manageragents along with priority requests for network Ticket servers maintain a model of the dynamic crisiscontext of the network and issue tickets according to auser's identity, organization, and need in the current This work was partially supported by the Madisonand Lila Self Graduate Fellowship at the University ofKansascontext. Ticket servers maintain this context modelthrough coordination with local, regional, and nationaldisaster control centers.

5 This architecture supplementsInternet Engineering Task Force (IETF) work on policyframeworks and directory enabled networks [4, 5] byproviding a dynamically adaptive mechanism forprioritizing user addition to these dynamic models of the networkcontext, this architecture also provides users with greatflexibility in negotiating for importance tickets. Users areable to request tickets directly, find out why tickets werenot granted, update information, provide authenticationresources to verify information they have provided, andeven request that the Server reconsider its view of thecurrent context to match the user's view of that context.

6 Itis of great benefit to users, especially in tense conditionscaused by a crisis, to have these capabilities. Intelligentagent technology and agent communication languages( , the Knowledge Query and Manipulation Language,KQML [6]) are used to provide automated mechanismsthat facilitate this interaction for the important Performance issues must beconsidered with such an architecture. Interaction withticket servers should not cause prohibitively longconnection setup times, Ticket Server performancerequirements must be reasonable, and excessive amounts ofnetwork overhead traffic must not be generated.

7 Thispaper will show that these issues are not significant enoughto prevent a successful implementation of the architecture,especially in light of the benefits such an architecturewould quantitative Performance analysis of thisarchitecture was conducted Using a useful approach thatcombined system prototyping and analytical networkEnd UserNetworkManagerAgentNetworkManagerAge ntEnd UserAuthenticationResourcesLocal, Regional, andNational DisasterControl CentersImportanceTicketSer versFigure 1. Connection Importance AdministrationArchitecturequeueing analysis.

8 This methodology was then used tosimulate a hurricane event and an office building bombingevent similar to the Alfred P. Murrah Federal BuildingBombing in Oklahoma City in 1995 [7].SYSTEM PROTOTYPE DESIGNS ince users interact and negotiate with Ticket serversusing intelligent agents and an agent communicationlanguage, the first objective of this research was to create asystem prototype to imitate these interactions. User andticket Server processes were created Using Java AgentTemplate, Lite (JATLite) [8] that provides extensions tothe Java programming language to support agentcommunication Using KQML [6].

9 To provide intelligentagent capabilities, the Java Expert System Shell (JESS) [9]was used. This provided a rule-based expert system shellfor user agents to generate requests for tickets and respondto responses to those requests. JESS was also used forserver processes to respond to requests for tickets based onthe current dynamic context and respond to user requests torenegotiate tickets. Ticket Server processes alsoimplemented rudimentary mechanisms for guardingagainst harmful user behaviors. One example was amechanism for ending a negotiation session once it wasunlikely that a user's further interaction would significantlyimprove a Ticket .

10 If not controlled, such user behaviorcould generate excessive unnecessary load on purpose of the prototype was to characterize thenegotiation process for a particular profile. A profile wasdefined as the interaction of a user with a Ticket Server in acertain context. A series of profiles could then becombined into a scenario to observe the negotiationprocess timeline as context 2 shows the overall design of the user andserver processes for the prototype. The user processconsisted of the User Negotiator that performed thenegotiation activity for the user and generated KQML communication.


Related search queries