Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision Next revisionBoth sides next revision | ||
sutchwon [2007-07-04 08:42] – external edit 127.0.0.1 | sutchwon [2015-11-05 12:42] – maja | ||
---|---|---|---|
Line 4: | Line 4: | ||
Su< | Su< | ||
- | mostly in | + | Article by Nik Gaffney for the Time's Up Newsletter, October 2000 |
- | | + | |
+ | sutChwon | ||
+ | lagging behind, and skipping ahead | ||
+ | (brief and somewhat distracted musings concerning the nature of nodular transcriptronic pulse mechanic space inverters, amongst other things) | ||
- | ====areas of interest==== | + | sutChwon |
+ | = subject to change without notice | ||
- | ===content negotiation=== | + | [authors note: this piece has emerged from discussions before, during and after the closing the loop sessions in 02.2000eV. it deals with a protocol/ |
+ | ==== performance, | ||
- | ===protocol negotiation=== | ||
- | protocol sketching >> http:// | + | This article is essentially a digression into developments of various ideas that are either half baked, half hearted or half finished, none the less, worth pursuing. an attempt at describing a glue layer between indeterminate components. a framework for developing frameworks. another thing that can go wrong in a fragile, indeterminate system. it describes a system or series of protocols which may simply be described as facilitating collaboration between networked participants. it should operate in real time, delayed time or stuttering network time, enabling synchronisation, |
+ | it is more or less a given that different groups and individuals work in different ways in collaborative situations. there are a range of modes of production, interaction and even (perhaps most importantly) modes of explaining “how?”, “what?” and “why?”. a filmmaker, for example will approach a project quite differently than a musician, architect or programmer. it is not within the scope of this article to describe any of this in detail, apart from pointing out aspects of a system that should be flexible enough to work with such a range of approaches, and in fact enhance them. | ||
- | ===service discovery=== | + | Most of us are using networks in someway or another for the projects discussed, presented or developed during closing the loop. Since there is a range of approaches, methodologies and attitudes to this, it seems appropriate to think of methods which would facilitate connection between remote participants who may be uncertain of what data being sent, how the data would be used ,or why in fact, there is any data at all (since its just a game). |
- | Service Location Protocol http://www.openslp.org/ | + | The networked aspect of these projects can frequently be described as a struggle of connections and configurations fuelled by the “ecstasy of communication at a distance”. often, it is the network itself which is the object of fascination, |
+ | For the purposes of this text, i’ll refer to the system as “sutChwon”, | ||
- | RFC:2608 - Service Location Protocol, Version 2 | + | ==== connecting disparate elements ==== |
- | RFC:2609 - Service Templates and Service Schemes | ||
- | RFC:2610 - DHCP Options | + | There are no standard setups in this area, most of us who are using networks |
- | RFC:2614 - An API for Service Location Protocol | + | n[tp]M is envisioned as a glue (inter)layer, |
- | ===ad-hoc | + | most networking |
- | * [[ZeroConf]] (aka rendezvous) will shake hands with the unconfigured | + | the network layer; in which the computers exchange, and manage the exchange of packets of data. |
- | * AODV (Adhoc On Demand Distance Vector routing) http:// | + | the syntactic layer; in which quantifiable information about the data is exchanged. eg. what format the data is in, where it is (and where its going), what protocols are being used, node response times, connection reliability, |
- | + | ||
- | ===ad-hoc data exchange=== | + | |
- | ubf (a and b) is a language for transporting | + | the interpretation layer; in which the information collected |
+ | the conversation layer; in which humans talk about guinea pigs (amongst other things). | ||
+ | it is often useful and in fact necessary to be able to access several layers of abstraction from the basic tcp or udp layer, as well as several protocols. | ||
- | ===media sharing=== | + | sutChwon provides connections on usually distinct network layers, which may be automatic, or configured as required. |
+ | the most common setup i have seen for networked sound exchange in a performance context is an encoder/ | ||
+ | in order to fit between this range of setups, sutChwon should utilise existing technologies, | ||
- | * [[sukcSpit]] / / [[gulliBloon]] | + | ==== automation will save us all ==== |
- | * RFC:3080 - The Blocks Extensible Exchange Protocol (BEEP) | + | |
- | + | ||
+ | |||
+ | a substantial amount of information about network activity, data exchange and interconnection of parts can be obtained automatically and presented in a unified manner (hopefully at an appropriate level of detail). the system should be as automatable as possible, so it can be automated as required (which would depend on its context). for example, having a graphic display of who and what is connected to the network, what sources they are using/ | ||
+ | |||
+ | since the system is flexible and modular, this information can be displayed and used in a variety of ways, and also for a variety of purposes. display and presentation of this collected data is itself an active hci/ | ||
+ | |||
+ | ==== describing data ==== | ||
+ | |||
+ | |||
+ | known data formats can be understood using a MIME like mechanism, so they can be dealt with internally, or passed to relevant subsystems/ | ||
+ | |||
+ | the main purpose of this format for data description is to enable otherwise unreadable data to be used. this makes it possible for participants in the network to exchange data without necessarily knowing if the other participants can understand it. a consequence of having an interconnected network, is that if one node on the network can describe a data format, these descriptions can be shared with any nodes requiring them. | ||
+ | |||
+ | ==== describing protocols ==== | ||
+ | |||
+ | explaining how protocols are implemented in a generalized manner, or in a manner in which it can be handled by another program is a slightly trickier problem, but essentially dealt with in a similar way. a description of the protocol is passed to n[tp]M, which can choose to deal with it internally (if it has the capacity), send data to external programs or a combination of the two. for example, web based interface to a synth, with the form fields being assigned to controls on the synth. on another level, the html tags could be used to create sounds, or inversely, the synth output could be used to generate html data which is sent to a server by an external ftp program. | ||
+ | |||
+ | since a protocol is essentially a description of a state machine and the magic words to change it, or elicit a response from it, protocol descriptions could be implemented (at least skeletally) in some kind of finite state machine emulator which has assignable connections to other software. | ||
+ | |||
+ | protocol negotiation protocol | ||
+ | |||
+ | in order to be able to exchange data either as a single meaningful lump, or by using a specific protocol, both the sender and receiver need to be able to interpret this data, or dataflow. the traditional response to data arriving in an unknown format can usually fit into 2 categories 1) output junk 2) crash. | ||
+ | |||
+ | the n[tp]M model would facilitate the exchange of unknown, or arbitrary data with arbitrary protocols by establishing a protocol for the exchange of abstract descriptions of formats and protocols. | ||
+ | |||
+ | pnp is used when a n[tp]M node cant understand, interpret, or in fact do anything with a stream of data it is about to receive. | ||
+ | it seems there are 3 ways to handle data which is being sent in an unknown format, or using an unknown protocol. (in order of difficulty) | ||
+ | |||
+ | * display it anyway, using another protocol | ||
+ | * exchange information about the format/ | ||
+ | * try to learn the protocol (eg. challenge/ | ||
+ | of course there are the implicit 4th and 5th options - ignore it and crash. neither of which im intending on implementing (except possibly the ‘ignore’ option thru connecting data source to a /dev/null abstraction) | ||
+ | |||
+ | in order to establish an exchange of data that will be intelligible as possible to both the sender and receiver, the nodes go thru a series of query/ | ||
+ | |||
+ | there should be a range of methods for enhancing the reliability of pnp, a simple method would involve registries of known data formats, protocols, interoperabilty matrices and known conflicts. a more complex method could use machine learning techniques to analyse exchanges (or read rfcs) and, with some human feedback, build templates, or translators which would be made available to the network. | ||
+ | |||
+ | ==== development(s) ==== | ||
+ | |||
+ | |||
+ | since a working version of sutChwon involves the development of several interdependent parts to function as described, it may take some time before it becomes particularly useful. however, one of its advantages is that its usefulness is enhanced by a diverse network of interconnected parts, and the more diverse the parts, the more useful it becomes. | ||
+ | active development will consist of four main parts, | ||
+ | * formalising a specification of the protocols and description formats | ||
+ | * writing a basic reference implementation | ||
+ | * incorporating feedback from potential use(r)s to determine the accuracy and scope of the specification and the implementation. | ||
+ | * extensive testing in a wide range of existing systems | ||
+ | while each of these aspects is somewhat self contained, they are all absolutely necessary for n[tp]M to function in networks that are subject to change without notice. | ||
+ | |||
+ | ng oct 2000 | ||
+ | |||
+ | |||
+ | see also [[sutChwon Notes]] | ||