This document describes the networking
\ninfrastructure in use by BiLE.
\n
<\/p>\n
The goal of the infrastructure design
\nhas been flexibility for real time changes in sharing network data
\nand calling remote methods for users of languages like supercollider.
\n While this flexibility is somewhat lost to users of inflexible
\nlanguages like MAX, they, nevertheless, can benefit from having a
\nstructure for data sharing.
\n
<\/p>\n
<\/p>\n
Network
\nModels<\/B>
\n
<\/p>\n
If there is a good reason, for
\nexample, a remote user, we support OSCGroups as a means of sharing
\ndata.<\/p>\n
If all users are located together on
\nthe same subnet, then we use broadcast on port 57120.
\n
<\/p>\n
OSC
\nPrefix<\/B>
\n
<\/p>\n
By convention, all OSC messages start
\nwith ‘\/bile\/’<\/p>\n
Data
\nRestrictions<\/B>
\n
<\/p>\n
Strings must all be ASCII. Non ASCII
\ncharacters will be ignored.
\n
<\/p>\n
Establishing
\nCommunication<\/B>
\nIdentity<\/B><\/I>
\nID<\/B>
\n Upon joining the network, users
\nshould announce their identity:<\/p>\n
\/bile\/API\/ID
\nnickname ipaddress port<\/p>\n
nicknames must be ASCII only.<\/p>\n
Example:<\/B><\/I><\/p>\n
\/bile\/API\/ID
\nNick 192.168.1.66 57120<\/p>\n
Note that because broadcast
\nechoes back, users may see their own ID arrive as an announcement.<\/p>\n
IDQuery<\/B><\/p>\n
Users should also send out their
\nID in response to an IDQuery:<\/p>\n
\/bile\/API\/IDQery<\/p>\n
Users can send this message at
\nany time, in order to compile a list of everyone on the network.<\/p>\n
API<\/B><\/I>
\nQuery<\/B>
\n Users can enquire what methods
\nthey can remotely invoke and what data they can request.<\/p>\n
\/bile\/API\/Query<\/p>\n
In
\nreply to this, users should send \/bile\/API\/Key and \/bile\/API\/Shared
\n(see below)<\/p>\n
Key<\/B>
\n Keys represent remote methods.
\nThe user should report their accessible methods in response to a
\nQuery<\/p>\n
\/bile\/API\/Key
\nsymbol desc nickname<\/p>\n
The symbol is an OSC message
\nthat the user is listening for.
\n The desc is a text based
\ndescription of what this message does. It should include a usage
\nexample.
\n The nickname is the name of the
\nuser that accepts this message.<\/p>\n
Example<\/B><\/I><\/p>\n
\/bile\/API\/Key
\n\/bile\/msg "For chatting. Usage: msg, nick, text" Nick
\n Shared<\/B>
\n Shared represents available
\ndata streams. Sources may include input devices, control data sent
\nto running audio processes or analysis. The user should report their
\nshared data response to a Query
\n \/bile\/API\/Shared
\n symbol desc
\n The symbol is an OSC message
\nthat the user sends with. The format of this should be<\/p>\n
\/bile\/nickname\/symbol
\n The desc is a text based
\ndescription of the data. If the range is not between 0-1, it should
\nmention this.
\n The nickname is the name of the
\nuser that accepts this message.<\/p>\n
Example<\/B><\/I>
\n \/bile\/API\/Shared
\n\/bile\/Nick\/freq "Frequency. Not scaled."<\/p>\n
Listening<\/B>
\nRegisterListener<\/B>
\n Shared data will not be sent out if no one has requested
\nit and it may be sent either directly to interested users or to the
\nentire group, at the sender’s discretion. In order to ensure
\nreceiving the data stream, a user must register as a listener.
\n \/bile\/API\/registerListener
\nsymbol nickname ip port
\n The symbol is an OSC message
\nthat the user will listening for. It should correspond with a
\npreviously advertised shared item. If the receiver of this message
\nrecognises their own nickname in in the symbol (which is formatted
\n\/bile\/nickname\/symbol),
\nthey should return an error:
\n\/bileAPI\/Error\/noSuchSymbol<\/p>\n
The nickname is the name of the
\nuser that will accept the symbol as a message.
\n The ip is the ip address of the
\nuser that will accept the symbol as a message.
\n The port is the port of the
\nuser that will accept the symbol as a message.
\nExample<\/B><\/I>
\n \/bile\/API\/registerListener
\n\/bile\/Nick\/freq Shelly 192.168.1.67 57120
\n
<\/p>\n
Error<\/B><\/I><\/p>\n
noSuchSymbol<\/B>
\n In the case that a user receives a request to register a
\nlistener or to remove a listener for data that they are not sharing,
\nthey can reply with <\/p>\n
\/bile\/API\/Error\/noSuchSymbol
\nOSCsymbol
\n The symbol is an OSC message
\nthat the user tried to start or stop listening to. It is formatted
\n\/bile\/nickname\/symbol.
\n Users should not reply with an error unless they recognise their own
\nnickname as the middle element of the OSC message. This message may
\nbe sent directly to the confused user.
\n
<\/p>\n
Example<\/B><\/I><\/p>\n
\/bile\/API\/Error\/noSuchSymbol
\n\/bile\/Nick\/freq
\nDe-listening<\/B><\/I>
\nRemoveListener<\/B>
\n To announce an intention to ignore subsequent data, a
\nuser can ask to be removed.
\n \/bile\/API\/removeListener
\nsymbol nickname ip
\n The symbol is an OSC message
\nthat the user will no longer be listening for. If the receiver of
\nthis message sees their nickname in the symbol which is formatted<\/p>\n
\/bile\/nickname\/symbol),
\nthey can reply with \/bile\/API\/Error\/noSuchSymbol
\nsymbol
\n The nickname is the name of the
\nuser that will no longer accept the symbol as a message.
\n The ip is the ip address of the
\nuser that will no longer accept the symbol as a message.
\nExample<\/B><\/I>
\n \/bile\/API\/removeListener
\n \/bile\/Nick\/freq Shelly 192.168.1.67
\nRemoveAll<\/B><\/p>\n
Users who are quitting the network can asked to be
\nremoved from everything that they were listening to.
\n \/bile\/API\/removeAll
\n nickname ip <\/p>\n
The nickname is the name of the
\nuser that will no longer accept any shared data.
\n The ip is the ip address of the
\nuser that will no longer accept any shared data.
\nExample<\/B><\/I>
\n \/bile\/API\/removeAll
\n Nick 192.168.1.66<\/p>\n
Commonly
\nUsed Messages<\/B>
\nChatting<\/B><\/I>
\nMsg<\/B>
\n This is used for chatting.
\n \/bile\/msg
\nnickname text
\n The nickname is the name of the
\nuser who is sending the message.
\n The text is the text that the
\nuser wishes to send to the group.<\/p>\n
Clock<\/B><\/I>
\n This is for a shared stopwatch and not for serious
\ntiming applications
\nClock start or
\nstop<\/B>
\n \/bile\/clock\/clock
\nsymbol
\n The symbol is either start or
\nstop.
\nReset<\/B><\/p>\n
Reset the clock to zero.
\n \/bile\/clock\/reset
\nSet<\/B>
\n Set the clock time
\n \/bile\/clock\/set
\nminutes seconds
\n Minutes is the number of minutes past zero.<\/p>\n
Seconds is the number of seconds past zero.
\n
<\/p>\n
Proposed
\nAdditions<\/B>
\n Because users can silently join, leave
\nand re-join the network, it could be a good idea to have users time
\nout after a period of silence, maybe around 30 seconds or so. To
\nstay active, they would need to send I’m-still-here messages.<\/p>\n
There should possibly also be a way
\nfor a user to announce that they have just arrived, so, for example,
\nif a SuperCollider user recompiles, her connection will think of
\nitself as new and other users will need to delete or recreate
\nconnections depending on that user.<\/p>\n","protected":false},"excerpt":{"rendered":"
This document describes the networking infrastructure in use by BiLE. The goal of the infrastructure design has been flexibility for real time changes in sharing network data and calling remote methods for users of languages like supercollider. While this flexibility is somewhat lost to users of inflexible languages like MAX, they, nevertheless, can benefit from … Continue reading Dissertation: BiLE Networking White Paper<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":""},"categories":[1],"tags":[112,76,122],"class_list":["post-190","post","type-post","status-publish","format-standard","hentry","category-uncategorised","tag-bile","tag-celesteh","tag-thesis"],"_links":{"self":[{"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/posts\/190","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/comments?post=190"}],"version-history":[{"count":1,"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/posts\/190\/revisions"}],"predecessor-version":[{"id":2389,"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/posts\/190\/revisions\/2389"}],"wp:attachment":[{"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/media?parent=190"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/categories?post=190"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.celesteh.com\/blog\/wp-json\/wp\/v2\/tags?post=190"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}