DOCSLIB.ORG

Message Queuing for Network Monitoring

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Message Queuing for Network Monitoring Faculty of Computing and Mathematical Sciences Department of Computer Science Message Queuing for Network Monitoring Anthony James Coddington Report of an Investigation 2012 The University of Waikato, Hamilton, New Zealand Message Queuing for Network Monitoring Anthony James Coddington This report is submitted in partial fulfillment of the requirements for the degree of Bachelor of Computing and Mathematical Sciences with Honours (BCMS(Hons)) at The University of Waikato. COMP520-12C (HAM) © 2012 Anthony James Coddington Abstract Network monitoring systems, such as the AMP project, are more useful when measurements are taken from a diverse range of locations in order to provide information from different parts of networks. Modern messaging protocols, such as those based on AMQP (Advanced Message Queuing Protocol), allow for more flexible, generic and potentially interoperable message routing and more sophisticated test co-ordination than those currently used by AMP; but many are not designed with the requirements of network monitoring in mind. This project was to investigate messaging protocols and their reliability and scalability in wide area networks, particularly with regards to coping when networks may not be behaving correctly (where network monitoring is most useful); and recommend a solution for network monitoring systems. No com- plete existing system that met all of the requirements of AMP was found, so a new client based on the STOMP protocol was implemented, which is compat- ible with a variety of messaging system implementations. This client includes a number of the features required for robust network monitoring, including a client-side persistence system and automatic re-connection to improve robust- ness to network failure. To further improve flexibility and resilience to failure, a system for extending STOMP to support direct peer-to-peer communication between measurement nodes is also proposed. Acknowledgements I would like to thank my supervisor, Richard Nelson for his excellent guidance throughout the project. I would also like to thank Brendon Jones for his helpful explanations of AMP, and in editing this report. Finally, I would like to thank the entire WAND group for their tireless help with my C coding questions throughout the project, I have learned an enormous amount this year. Contents Abstract ii Acknowledgements iii 1 Introduction1 2 Background3 2.1 AMP Overview.........................3 2.2 Requirements..........................5 2.3 Messaging-Oriented Middleware................5 2.4 Types of Message System....................6 2.4.1 Messaging Queuing Systems.................6 2.4.2 Publish-Subscribe Systems..................6 2.5 Message Brokers.........................6 3 Existing Systems8 3.1 Advanced Message Queuing Protocol.............8 3.2 ZeroMQ.............................9 3.3 Log Collection Systems..................... 10 3.3.1 Facebook Scribe....................... 10 3.4 MQ Telemetry Transport.................... 11 3.5 ActiveMQ............................ 12 3.6 Simple (or Streaming) Text Orientated Messaging Protocol (STOMP)............................ 12 3.7 Conclusion............................ 13 4 Architecture 15 4.1 STOMP............................. 15 4.1.1 STOMP Frame Types.................... 16 4.1.2 Extensibility......................... 17 Contents v 4.1.3 Limitations.......................... 17 4.1.4 Existing C/C++ Clients................... 18 4.1.5 STOMP 1.1.......................... 18 4.2 Design.............................. 19 4.3 Security............................. 19 4.4 Persistence............................ 19 4.5 End-to-end Acknowledgements................. 20 4.6 Non-blocking Connections................... 20 5 Implementation 22 5.1 Initial Implementation..................... 22 5.2 Frame Abstraction....................... 22 5.3 Persistence............................ 23 5.4 Non-blocking Connection.................... 23 5.5 Acknowledgements and Re-connection............. 24 6 Evaluation 25 6.1 Testing.............................. 25 6.2 Challenges............................ 25 6.3 Evaluation against Requirements............... 26 6.4 Future Work........................... 27 6.4.1 Completion of Persistence Integration and Reliability... 27 6.4.2 Peer-to-peer.......................... 27 6.4.3 Additional STOMP Features................. 30 6.4.4 Further Investigation of Broker-side Features........ 30 6.4.5 AMP Integration....................... 30 7 Conclusion 32 References 33 List of Figures 2.1 AMP Architecture...........................4 2.2 Broker-centric message-oriented middleware.............7 4.1 A STOMP SEND frame sent by publishers to the broker, and its corresponding MESSAGE frame, sent by the broker to subscribers.. 16 6.1 Peer distribution STOMP with re-sender............... 29 List of Tables 3.1 Surveyed Messaging Systems..................... 14 List of Acronyms AMQP Advanced Message Queuing Protocol MQTT MQ Telemetry Transport STOMP Simple (or Streaming) Text Orientated Messaging Protocol SSL Secure Socket Layer RFC Request for Comment SASL Simple Authentication and Security Layer RPC Remote Procedure Call API Application Programming Interface JMS Java Message Service WAN Wide Area Network CMS C++ Messaging Service APR Apache Portable Runtime HTTP Hypertext Transfer Protocol HTTPS HTTP Secure TCP Transmission Control Protocol WAL Write Ahead Logging I/O Input/Output LDAP Lightweight Directory Access Protocol Chapter 1 Introduction Generic, flexible messaging middleware is popular, with a wide variety of imple- mentations; but many systems have not been designed with the requirements of network monitoring in mind, the most important of which is robustness to network failure. This project was to select and implement a more flexible and generic messaging system suitable for use in the AMP active network monitor- ing system that could be used to allow more sophisticated test co-ordination, and better support for multiple collection servers; with increased reliability. It was considered desirable, but not essential that the system could be used for other messaging in addition to network monitoring applications. The original aim of the project was to investigate and select an existing mes- saging system for network monitoring, and integrate the system into AMP. As the investigation continued, it became clear that there were not any existing messaging systems that met the requirements for AMP, which is written in C and designed to be lightweight with minimal dependencies (WAND Net- work Research Group, n.d.b). Systems were found to be one or more of: too large to run on lightweight nodes (making use of Java on the client-side for example); lacking support for secure authentication of message origin (which is required for deployment in Wide Area Networks (WANs)); or lacking support for client-side persistence. As it became clear that extensive client work would be required, extension of the existing messaging system was considered. It was decided that the use of the simple STOMP protocol described in STOMP (2011), which is supported by many different messaging systems, would bring benefits of interoperability with other systems through a standardised format, while still remaining simple and being more flexible than the current system. Chapter 1 Introduction 2 After determining that existing STOMP C libraries were unsuitable the deci- sion was made to implement a new STOMP 1.1 library, of which none existed for the C language. To achieve this, a basic low-level frame handling layer was written, similar to one of the existing libraries, but with the addition of support for security. Following this, a significantly higher level Application Programming Interface (API) was added, as well as a high-level client-side persistence system that used a mature backing store to facilitate robustness. Finally, an architecture was designed extending STOMP to support a peer-to- peer communication directly between nodes. Chapter2 of this report gives an overview of AMP and messaging-oriented middleware, and details requirements identified for the system. Chapter3 focuses on existing messaging systems surveyed in a major initial investigation at the beginning of the project. Chapter4 discusses the STOMP protocol in more detail, and the design of the system implemented. Chapter5 describes the implementation completed as part of the project. Chapter6 describes the testing undertaken, and an evaluation of the system as currently implemented against the requirements identified in Section 2.2; followed by a discussion of future work that was not included in the implementation, including discussion of approaches designed to extend STOMP to work in a decentralised manner. Finally, Chapter7 is a conclusion summarising the outcomes of the project. Chapter 2 Background This chapter includes an overview of AMP and its messaging system, and details the requirements of any replacement system. An overview of the main types of messaging middleware is then presented. 2.1 AMP Overview The AMP project, developed by the National Laboratory for Applied Network Research (NLANR), now maintained by The University of Waikato WAND research group, is a distributed active probe network monitoring system. At its peak there were at least 130 nodes in operation, mostly located in the United States of America (McGregor, 2002). AMP in New Zealand is now primarily used to monitor Internet service provider and university networks around the country, as well as the REANNZ research network; with approximately
Load more

Recommended publications
  • Evaluating DDS, MQTT, and Zeromq Under Different Iot Traffic Conditions
    Evaluating DDS, MQTT, and ZeroMQ Under Different IoT Traffic Conditions Zhuangwei Kang Robert Canady Abhishek Dubey Vanderbilt University Vanderbilt University Vanderbilt University Nashville, Tennessee Nashville, Tennessee Nashville, Tennessee [email protected] [email protected] [email protected] Aniruddha Gokhale Shashank Shekhar Matous Sedlacek Vanderbilt University Siemens Technology Siemens Technology Nashville, Tennessee Princeton, New Jersey Munich, Germany [email protected] [email protected] [email protected] Abstract Keywords: Publish/Subscribe Middleware, Benchmark- ing, MQTT, DDS, ZeroMQ, Performance Evaluation Publish/Subscribe (pub/sub) semantics are critical for IoT applications due to their loosely coupled nature. Although OMG DDS, MQTT, and ZeroMQ are mature pub/sub solutions used for IoT, prior studies show that their performance varies significantly under different 1 Introduction load conditions and QoS configurations, which makes Distributed deployment of real-time applications and middleware selection and configuration decisions hard. high-speed dissemination of massive data have been hall- Moreover, the load conditions and role of QoS settings in marks of the Internet of Things (IoT) platforms. IoT prior comparison studies are not comprehensive and well- applications typically adopt publish/subscribe (pub/- documented. To address these limitations, we (1) propose sub) middleware for asynchronous and cross-platform a set of performance-related properties for pub/sub mid- communication. OMG Data Distribution Service (DDS), dleware and investigate their support in DDS, MQTT, ZeroMQ, and MQTT are three representative pub/sub and ZeroMQ; (2) perform systematic experiments under technologies that have entirely different architectures (de- three representative, lab-based real-world IoT use cases; centralized data-centric, decentralized message-centric, and (3) improve DDS performance by applying three and centralized message-centric, respectively).
    [Show full text]
  • This Paper Must Be Cited As
    Document downloaded from: http://hdl.handle.net/10251/64607 This paper must be cited as: Luzuriaga Quichimbo, JE.; Pérez, M.; Boronat, P.; Cano Escribá, JC.; Tavares De Araujo Cesariny Calafate, CM.; Manzoni, P. (2015). A comparative evaluation of AMQP and MQTT protocols over unstable and mobile networks. 12th IEEE Consumer Communications and Networking Conference (CCNC 2015). IEEE. doi:10.1109/CCNC.2015.7158101. The final publication is available at http://dx.doi.org/10.1109/CCNC.2015.7158101 Copyright IEEE Additional Information © 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. A comparative evaluation of AMQP and MQTT protocols over unstable and mobile networks Jorge E. Luzuriaga∗, Miguel Perezy, Pablo Boronaty, Juan Carlos Cano∗, Carlos Calafate∗, Pietro Manzoni∗ ∗Department of Computer Engineering Universitat Politecnica` de Valencia,` Valencia, SPAIN [email protected], jucano,calafate,[email protected] yUniversitat Jaume I, Castello´ de la Plana, SPAIN [email protected], [email protected] Abstract—Message oriented middleware (MOM) refers to business application [6]. It works like instant messaging or the software infrastructure supporting sending and receiving email, and the difference towards these available
    [Show full text]
  • Enterprise Integration Patterns N About Apache Camel N Essential Patterns Enterprise Integration Patterns N Conclusions and More
    Brought to you by... #47 CONTENTS INCLUDE: n About Enterprise Integration Patterns n About Apache Camel n Essential Patterns Enterprise Integration Patterns n Conclusions and more... with Apache Camel Visit refcardz.com By Claus Ibsen ABOUT ENTERPRISE INTEGRATION PaTTERNS Problem A single event often triggers a sequence of processing steps Solution Use Pipes and Filters to divide a larger processing steps (filters) that are connected by channels (pipes) Integration is a hard problem. To help deal with the complexity Camel Camel supports Pipes and Filters using the pipeline node. of integration problems the Enterprise Integration Patterns Java DSL from(“jms:queue:order:in”).pipeline(“direct:transformOrd (EIP) have become the standard way to describe, document er”, “direct:validateOrder”, “jms:queue:order:process”); and implement complex integration problems. Hohpe & Where jms represents the JMS component used for consuming JMS messages Woolf’s book the Enterprise Integration Patterns has become on the JMS broker. Direct is used for combining endpoints in a synchronous fashion, allow you to divide routes into sub routes and/or reuse common routes. the bible in the integration space – essential reading for any Tip: Pipeline is the default mode of operation when you specify multiple integration professional. outputs, so it can be omitted and replaced with the more common node: from(“jms:queue:order:in”).to(“direct:transformOrder”, “direct:validateOrder”, “jms:queue:order:process”); Apache Camel is an open source project for implementing TIP: You can also separate each step as individual to nodes: the EIP easily in a few lines of Java code or Spring XML from(“jms:queue:order:in”) configuration.
    [Show full text]
  • Tracking Known Security Vulnerabilities in Third-Party Components
    Tracking known security vulnerabilities in third-party components Master’s Thesis Mircea Cadariu Tracking known security vulnerabilities in third-party components THESIS submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in COMPUTER SCIENCE by Mircea Cadariu born in Brasov, Romania Software Engineering Research Group Software Improvement Group Department of Software Technology Rembrandt Tower, 15th floor Faculty EEMCS, Delft University of Technology Amstelplein 1 - 1096HA Delft, the Netherlands Amsterdam, the Netherlands www.ewi.tudelft.nl www.sig.eu c 2014 Mircea Cadariu. All rights reserved. Tracking known security vulnerabilities in third-party components Author: Mircea Cadariu Student id: 4252373 Email: [email protected] Abstract Known security vulnerabilities are introduced in software systems as a result of de- pending on third-party components. These documented software weaknesses are hiding in plain sight and represent the lowest hanging fruit for attackers. Despite the risk they introduce for software systems, it has been shown that developers consistently download vulnerable components from public repositories. We show that these downloads indeed find their way in many industrial and open-source software systems. In order to improve the status quo, we introduce the Vulnerability Alert Service, a tool-based process to track known vulnerabilities in software projects throughout the development process. Its usefulness has been empirically validated in the context of the external software product quality monitoring service offered by the Software Improvement Group, a software consultancy company based in Amsterdam, the Netherlands. Thesis Committee: Chair: Prof. Dr. A. van Deursen, Faculty EEMCS, TU Delft University supervisor: Prof. Dr. A.
    [Show full text]
  • Unravel Data Systems Version 4.5
    UNRAVEL DATA SYSTEMS VERSION 4.5 Component name Component version name License names jQuery 1.8.2 MIT License Apache Tomcat 5.5.23 Apache License 2.0 Tachyon Project POM 0.8.2 Apache License 2.0 Apache Directory LDAP API Model 1.0.0-M20 Apache License 2.0 apache/incubator-heron 0.16.5.1 Apache License 2.0 Maven Plugin API 3.0.4 Apache License 2.0 ApacheDS Authentication Interceptor 2.0.0-M15 Apache License 2.0 Apache Directory LDAP API Extras ACI 1.0.0-M20 Apache License 2.0 Apache HttpComponents Core 4.3.3 Apache License 2.0 Spark Project Tags 2.0.0-preview Apache License 2.0 Curator Testing 3.3.0 Apache License 2.0 Apache HttpComponents Core 4.4.5 Apache License 2.0 Apache Commons Daemon 1.0.15 Apache License 2.0 classworlds 2.4 Apache License 2.0 abego TreeLayout Core 1.0.1 BSD 3-clause "New" or "Revised" License jackson-core 2.8.6 Apache License 2.0 Lucene Join 6.6.1 Apache License 2.0 Apache Commons CLI 1.3-cloudera-pre-r1439998 Apache License 2.0 hive-apache 0.5 Apache License 2.0 scala-parser-combinators 1.0.4 BSD 3-clause "New" or "Revised" License com.springsource.javax.xml.bind 2.1.7 Common Development and Distribution License 1.0 SnakeYAML 1.15 Apache License 2.0 JUnit 4.12 Common Public License 1.0 ApacheDS Protocol Kerberos 2.0.0-M12 Apache License 2.0 Apache Groovy 2.4.6 Apache License 2.0 JGraphT - Core 1.2.0 (GNU Lesser General Public License v2.1 or later AND Eclipse Public License 1.0) chill-java 0.5.0 Apache License 2.0 Apache Commons Logging 1.2 Apache License 2.0 OpenCensus 0.12.3 Apache License 2.0 ApacheDS Protocol
    [Show full text]
  • Talend Open Studio for Big Data Release Notes
    Talend Open Studio for Big Data Release Notes 6.0.0 Talend Open Studio for Big Data Adapted for v6.0.0. Supersedes previous releases. Publication date July 2, 2015 Copyleft This documentation is provided under the terms of the Creative Commons Public License (CCPL). For more information about what you can and cannot do with this documentation in accordance with the CCPL, please read: http://creativecommons.org/licenses/by-nc-sa/2.0/ Notices Talend is a trademark of Talend, Inc. All brands, product names, company names, trademarks and service marks are the properties of their respective owners. License Agreement The software described in this documentation is licensed under the Apache License, Version 2.0 (the "License"); you may not use this software except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.html. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. This product includes software developed at AOP Alliance (Java/J2EE AOP standards), ASM, Amazon, AntlR, Apache ActiveMQ, Apache Ant, Apache Avro, Apache Axiom, Apache Axis, Apache Axis 2, Apache Batik, Apache CXF, Apache Cassandra, Apache Chemistry, Apache Common Http Client, Apache Common Http Core, Apache Commons, Apache Commons Bcel, Apache Commons JxPath, Apache
    [Show full text]
  • Vimal Daga Chief Technical Officer (CTO) – Linuxworld Informatics Pvt Ltd Professional Experience & Certifications
    Vimal Daga Chief Technical Officer (CTO) – LinuxWorld Informatics Pvt Ltd Professional Experience & Certifications: I Professional Experience During this period, has been engaged with various corporate clients on different domains and has been involved in imparting corporate Training programs and Consultancy for various technologies that covers the following: A. Sr. Machine Learning / Deep Learning / Data Scientist / NLP Consultant and Researcher Expertise in the field of Artificial Intelligence, Deep Learning, and Computer Vision and having ability to solve problems such as Face Detection, Face Recognition and Object Detection using Deep Neural Network (CNN, DNN, RNN, Convolution Networks etc.) and Optical Character Detection and Recognition (OCD & OCR) Worked in tools such as Tensorflow, Caffe/Caffe2, Keras, Theano, PyTorch etc. Build prototypes related to deep learning problems in the field of computer vision. Publications at top international conferences/ journals in fields related to computer vision/deep learning/machine learning / AI Experience on tools, frameworks like Microsoft Azure ML, Chat Bot Framework/LUIS . IBM Watson / ConversationService, Google TensorFlow / Python for Machine Learning (e.g. scikit-learn),Open source ML libraries and tools like Apache Spark Highly Worked on Data Science, Big Data,datastructures, statistics , algorithms like Regression, Classification etc. Working knowlegde of Supervised / Unsuperivsed learning (Decision Trees, Logistic Regression, SVMs,GBM, etc) Expertise in Sentiment Analysis, Entity Extraction, Natural Language Understanding (NLU), Intent recognition Strong understanding of text pre-processing and normalization techniques, such as tokenization, POS tagging, and parsing, and how they work at a basic level and NLP toolkits as NLTK, Gensim,, Apac SpaCyhe UIMA etc. I have Hands on experience related to Datasets such as or including text, images and other logs or clickstreams.
    [Show full text]
  • Advanced Architecture for Java Universal Message Passing (AA-JUMP)
    The International Arab Journal of Information Technology, Vol. 15, No. 3, May 2018 429 Advanced Architecture for Java Universal Message Passing (AA-JUMP) Adeel-ur-Rehman1 and Naveed Riaz2 1National Centre for Physics, Pakistan 2School of Electrical Engineering and Computer Science, National University of Science and Technology, Pakistan Abstract: The Architecture for Java Universal Message Passing (A-JUMP) is a Java based message passing framework. A- JUMP offers flexibility for programmers in order to write parallel applications making use of multiple programming languages. There is also a provision to use various network protocols for message communication. The results for standard benchmarks like ping-pong latency, Embarrassingly Parallel (EP) code execution, Java Grande Forum (JGF) Crypt etc. gave us the conclusion that for the cases where the data size is smaller than 256K bytes, the numbers are comparative with some of its predecessor models like Message Passing Interface CHameleon version 2 (MPICH2), Message Passing interface for Java (MPJ) Express etc. But, in case, the packet size exceeds 256K bytes, the performance of the A-JUMP model seems to be severely hampered. Hence, taking that peculiar behaviour into account, this paper talks about a strategy devised to cope up with the performance limitation observed under the base A-JUMP implementation, giving birth to an Advanced A-JUMP (AA- JUMP) methodology while keeping the basic workflow of the original model intact. AA-JUMP addresses to improve performance of A-JUMP by preserving its various traits like portability, simplicity, scalability etc. which are the key features offered by flourishing High Performance Computing (HPC) oriented frameworks of now-a-days.
    [Show full text]
  • Habari Client for Activemq Version 4.1
    Getting started with Habari Client for ActiveMQ Version 4.1 Trademarks Habari is a registered trademark of Michael Justin and is protected by the laws of Germany and other countries. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Embarcadero, the Embarcadero Technologies logos and all other Embarcadero Technologies product or service names are trademarks, service marks, and/or registered trademarks of Embarcadero Technologies, Inc. and are pro­ tected by the laws of the United States and other countries. Microsoft, Windows, Windows NT, and/or other Microsoft products referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other brands and their products are trademarks of their respective holders. 2 Habari Client for ActiveMQ 4.1 Contents What's new in version 4.1?...................................................................6 Fixes and improvements...................................................................................6 Core library.....................................................................................................6 Conditional symbol HABARI_SSL_SUPPORT.....................................................6 Tests and demo projects...................................................................................6 Documentation................................................................................................7 Broker specific changes....................................................................................7
    [Show full text]
  • Dcamp: Distributed Common Api for Measuring
    DCAMP: DISTRIBUTED COMMON API FOR MEASURING PERFORMANCE A Thesis presented to the Faculty of California Polytechnic State University San Luis Obispo In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by Alexander Paul Sideropoulos December 2014 c 2014 Alexander Paul Sideropoulos ALL RIGHTS RESERVED ii COMMITTEE MEMBERSHIP TITLE: dCAMP: Distributed Common API for Measuring Performance AUTHOR: Alexander Paul Sideropoulos DATE SUBMITTED: December 2014 COMMITTEE CHAIR: Michael Haungs, Ph.D. Associate Professor of Computer Science COMMITTEE MEMBER: Aaron Keen, Ph.D. Assistant Professor of Computer Science COMMITTEE MEMBER: John Bellardo, Ph.D. Associate Professor of Computer Science iii ABSTRACT dCAMP: Distributed Common API for Measuring Performance Alexander Paul Sideropoulos Although the nearing end of Moore's Law has been predicted numerous times in the past [22], it will eventually come to pass. In forethought of this, many modern computing systems have become increasingly complex, distributed, and parallel. As software is developed on and for these complex systems, a common API is necessary for gathering vital performance related metrics while remaining transparent to the user, both in terms of system impact and ease of use. Several distributed performance monitoring and testing systems have been proposed and implemented by both research and commercial institutions. How- ever, most of these systems do not meet several fundamental criterion for a truly useful distributed performance monitoring system: 1) variable data delivery mod- els, 2) security, 3) scalability, 4) transparency, 5) completeness, 6) validity, and 7) portability [30]. This work presents dCAMP: Distributed Common API for Measuring Per- formance, a distributed performance framework built on top of Mark Gabel and Michael Haungs' work with CAMP.
    [Show full text]
  • Return of Organization Exempt from Income
    OMB No. 1545-0047 Return of Organization Exempt From Income Tax Form 990 Under section 501(c), 527, or 4947(a)(1) of the Internal Revenue Code (except black lung benefit trust or private foundation) Open to Public Department of the Treasury Internal Revenue Service The organization may have to use a copy of this return to satisfy state reporting requirements. Inspection A For the 2011 calendar year, or tax year beginning 5/1/2011 , and ending 4/30/2012 B Check if applicable: C Name of organization The Apache Software Foundation D Employer identification number Address change Doing Business As 47-0825376 Name change Number and street (or P.O. box if mail is not delivered to street address) Room/suite E Telephone number Initial return 1901 Munsey Drive (909) 374-9776 Terminated City or town, state or country, and ZIP + 4 Amended return Forest Hill MD 21050-2747 G Gross receipts $ 554,439 Application pending F Name and address of principal officer: H(a) Is this a group return for affiliates? Yes X No Jim Jagielski 1901 Munsey Drive, Forest Hill, MD 21050-2747 H(b) Are all affiliates included? Yes No I Tax-exempt status: X 501(c)(3) 501(c) ( ) (insert no.) 4947(a)(1) or 527 If "No," attach a list. (see instructions) J Website: http://www.apache.org/ H(c) Group exemption number K Form of organization: X Corporation Trust Association Other L Year of formation: 1999 M State of legal domicile: MD Part I Summary 1 Briefly describe the organization's mission or most significant activities: to provide open source software to the public that we sponsor free of charge 2 Check this box if the organization discontinued its operations or disposed of more than 25% of its net assets.
    [Show full text]
  • Malibu Library User's Manual Malibu Library User's Manual
    Malibu Library User's Manual Malibu Library User's Manual The Malibu Library User's Manual was prepared by the technical staff of Innovative Integration on December 10, 2013. For further assistance contact: Innovative Integration 2390-A Ward Ave Simi Valley, California 93065 PH: (805) 578-4260 FAX: (805) 578-4225 email: [email protected] Website: www.innovative-dsp.com This document is copyright 2013 by Innovative Integration. All rights are reserved. $/Distributions/Components/Malibu/Documentation/OO_Manual/Mali bu.pdf Rev 1.4 Table of Contents Chapter 1. Introduction..........................................................................................................................10 Real Time Solutions!.............................................................................................................................................................10 Vocabulary.............................................................................................................................................................................10 What is Malibu? ........................................................................................................................................................10 What is Microsoft MSVC?.........................................................................................................................................11 What is Qt?.................................................................................................................................................................11
    [Show full text]