# # Copyright (c) 2005 Richard Cameron, CiteULike.org # All rights reserved. # # This code is derived from software contributed to CiteULike.org # by: Diwaker Gupta # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by # CiteULike and its # contributors. # 4. Neither the name of CiteULike nor the names of its # contributors may be used to endorse or promote products derived # from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY CITEULIKE.ORG AND CONTRIBUTORS # ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED # TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS # BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF # SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN # CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ## # Each plugin needs a description so the driver can advertise the details # to the users on the site plugin { # Integer version number for the plugin code. When this number is incremented, # CiteULike may reparse all existing articles with the new code. version {1} # The name of the plugin, as displayed on the "CiteULike supports..." page name {Usenix} # The link the front page of this service url {http://www.usenix.org} # Any additional information which needs to be displayed to the user. # E.g. "Experimental support" blurb {} # Your name author {Diwaker Gupta} # Your email address email {diwakergupta AT yahoo DOT com} # Language you wrote the plugin in language {python} # Regular expression to match URLs that the plugin is # *potentially* interested in. Any URL matching this regexp # will cause your parser to be invoked. Currently, this will # require fork()ing a process, so you should try to reduce the number # of false positives by making your regexp as restrictive as possible. # # If it is not possible to determine whether or not your plugin is # interested purely on the basis of the URL, you will have a chance # to refine this decision in your code. For now, try to make a reasonable # approximation - like, check for URLs on the right hostname # # Note: Some universities provide mirrors of commericial publishers' sites # with different hostnames, so you should provide some leeway in your # regexp if that applies to you. # regexp {^http://www\.usenix\.org/(events/|publications/library/proceedings/)([^/]+/)tech/+([a-z]+\.html)$} regexp {^http://www\.usenix\.org/(events/|publications/library/proceedings/)([^/]+/)*([a-z]+\.html)$} } # # Linkout formatting # # CiteULike doesn't store URLs for articles. # Instead it stores the raw ingredients required to build the dynamically. # Each plugin is required to define a small procedure which does this formatting # See the HOWTO file for more details. # # # The variables following variables are defined for your use # in the function: type ikey_1 ckey_1 ikey_2 ckey_2 # format_linkout USENX { #return [list "USENIX (tech session)" \ #"http://www.usenix.org/events/${ckey_1}/tech/${ckey_2}.html" \ #"USENIX (library proceedings)" \ #"http://www.usenix.org/publications/library/proceedings/${ckey_1}/tech/${ckey_2}.html"] return [list "USENIX" "${ckey_1}"] } # # TESTS # # Each plugin MUST provide a set of tests. The motivation behind this is # that web scraping code is inherently fragile, and is likely to break whenever # the provider decides to redisign their site. CiteULike will periodically # run tests to see if anything has broken. # Please provide as comprehensive a set of tests as possible. # If you ever fix a bug in the parser, it is highly recommended that # you add the offending page as a test case. test {http://www.usenix.org/events/osdi04/tech/renesse.html} { formatted_url {USENIX http://www.usenix.org/events/osdi04/tech/renesse.html} author {{van Renesse} Robbert R {Robbert van Renesse}} author {Schneider Fred FB {Fred B. Schneider}} linkout {USENX {} http://www.usenix.org/events/osdi04/tech/renesse.html {} {}} start_page 91 end_page 104 title {Chain Replication for Supporting High Throughput and Availability} journal {OSDI '04} abstract {Chain replication is a new approach to coordinating clusters of fail- stop storage servers. The approach is intended for supporting large- scale storage services that exhibit high throughput and availability without sacrificing strong consistency guarantees. Besides outlining the chain replication protocols themselves, simulation experiments explore the performance characteristics of a prototype implementation. Throughput, availability, and several object-placement strategies (including schemes based on distributed hash table routing) are discussed.

} type INCONF status ok } test {http://www.usenix.org/events/osdi04/tech/swift.html} { formatted_url {USENIX http://www.usenix.org/events/osdi04/tech/swift.html} author {Swift Michael MM {Michael M. Swift}} author {Annamalai Muthukaruppan M {Muthukaruppan Annamalai}} author {Bershad Brian BN {Brian N. Bershad}} author {Levy Henry HM {Henry M. Levy}} linkout {USENX {} http://www.usenix.org/events/osdi04/tech/swift.html {} {}} start_page 1 end_page 16 title {Recovering Device Drivers} journal {OSDI '04} abstract {This paper presents a new mechanism that enables applications to run correctly when device drivers fail. Because device drivers are the principal failing component in most systems, reducing driver-induced failures greatly improves overall reliability. Earlier work has shown that an operating system can survive driver failures [33], but the applications that depend on them cannot. Thus, while operating system reliability was greatly improved, application reliability generally was not.

To remedy this situation, we introduce a new operating system mechanism called a shadow driver. A shadow driver monitors device drivers and transparently recovers from driver failures. Moreover, it assumes the role of the failed driver during recovery. In this way, applications using the failed driver, as well as the kernel itself, continue to function as expected.

We implemented shadow drivers for the Linux operating system and tested them on over a dozen device drivers. Our results show that applications and the OS can indeed survive the failure of a variety of device drivers. Moreover, shadow drivers impose minimal performance overhead. Lastly, they can be introduced with only modest changes to the OS kernel and with no changes at all to existing device drivers.

} type INCONF status ok } test {http://www.usenix.org/events/osdi02/tech/madden.html} { formatted_url {USENIX http://www.usenix.org/events/osdi02/tech/madden.html} abstract {We present the Tiny AGgregation (TAG) service for aggregation in low- power, distributed, wireless environments. TAG allows users to express simple, declarative queries and have them distributed and executed efficiently in networks of low-power, wireless sensors. We discuss various generic properties of aggregates, and show how those properties affect the performance of our in network approach. We include a performance study demonstrating the advantages of our approach over traditional centralized, out-of-network methods, and discuss a variety of optimizations for improving the performance and fault-tolerance of the basic solution.} linkout {USENX {} http://www.usenix.org/events/osdi02/tech/madden.html {} {}} author {Madden Samuel S {Samuel Madden}} author {Franklin Michael MJ {Michael J. Franklin}} author {Joseph {} {} {Joseph M. Hellerstein, University of California, Berkeley; Wei Hong}} title {TAG: A Tiny AGgregation Service for Ad-Hoc Sensor Networks} journal {OSDI '02} type INCONF status ok } test {http://www.usenix.org/publications/library/proceedings/sec98/paxson.html} { formatted_url {USENIX http://www.usenix.org/publications/library/proceedings/sec98/paxson.html} abstract {We describe Bro, a stand-alone system for detecting network intruders in real-time by passively monitoring a network link over which the intruder's traffic transits. We give an overview of the system's design, which emphasizes high-speed (FDDI-rate) monitoring, real-time notification, clear separation between mechanism and policy, and extensibility. To achieve these ends, Bro is divided into an ``event engine'' that reduces a kernel-filtered network traffic stream into a series of higher-level events, and a ``policy script interpreter'' that interprets event handlers written in a specialized language used to express a site's security policy. Event handlers can update state information, synthesize new events, record information to disk, and generate real-time notifications via syslog. We also discuss a number of attacks that attempt to subvert passive monitoring systems and defenses against these, and give particulars of how Bro analyzes the four applications integrated into it so far: Finger, FTP, Portmapper and Telnet. The system is publicly available in source code form.} linkout {USENX {} http://www.usenix.org/publications/library/proceedings/sec98/paxson.html {} {}} type INCONF title {Bro: A System for Detecting Network Intruders in Real-Time} status ok } test {http://www.usenix.org/events/usenix04/tech/freenix/kreibich.html} { formatted_url {USENIX http://www.usenix.org/events/usenix04/tech/freenix/kreibich.html} abstract {We present the design and implementation of a framework for inspection, visualization, and modification of tcpdump packet trace files. The system is modularized into components for distinct application purposes, readily extensible, accessible through programmatic and graphical interfaces, and capable of handling trace files of arbitrary size and content. We include experiences of using the system in several real-world scenarios.} linkout {USENX {} http://www.usenix.org/events/usenix04/tech/freenix/kreibich.html {} {}} author {Kreibich Christian C {Christian Kreibich}} title {Design and Implementation of Netdude, a Framework for Packet Trace Manipulation} start_page 63 end_page 72 journal {USENIX 2004 Annual Technical Conference, FREENIX Track} type INCONF status ok } test {http://www.usenix.org/events/sec01/handley.html} { formatted_url {USENIX http://www.usenix.org/events/sec01/handley.html} abstract {A fundamental problem for network intrusion detection systems is the ability of a skilled attacker to evade detection by exploiting ambiguities in the traffic stream as seen by the monitor. We discuss the viability of addressing this problem by introducing a new network forwarding element called a traffic normalizer. The normalizer sits directly in the path of traffic into a site and patches up the packet stream to eliminate potential ambiguities before the traffic is seen by the monitor, removing evasion opportunities. We examine a number of tradeoffs in designing a normalizer, emphasizing the important question of the degree to which normalizations undermine end-to-end protocol semantics. We discuss the key practical issues of ``cold start'' and attacks on the normalizer, and develop a methodology for systematically examining the ambiguities present in a protocol based on walking the protocol's header. We then present norm, a publicly available user-level implementation of a normalizer that can normalize a TCP traffic stream at 100,000 pkts/sec in memory-to-memory copies, suggesting that a kernel implementation using PC hardware could keep pace with a bidirectional 100 Mbps link with sufficient headroom to weather a high-speed flooding attack of small packets.} linkout {USENX {} http://www.usenix.org/events/sec01/handley.html {} {}} author {Mark {} H {Mark H}} author {Ley {} {} ley} author {Paxson Vern V {Vern Paxson}} title {Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics} journal {Security '01} type INCONF status ok }