netpd-server
the goal of the netpd-server simply is to connect clients with each other. therefore the intelligence of the netpd system is implemented on the client side, whereas the server is kept relatively dumb. it should be an easy task to implemented the netpd-server in any programming language other than pd. currently only pd implementations are known.
the netpd-server uses the protocol described on the protocol page. for implementing a server (in any programming language), only the <recipient> field needs to be considered.
current implementations
- netpd-server.pd
the original old, ugly and unchanged for years netpd-server patch. it provides additional functionality for logging chat and give log access for logview. it is based on [netserver] from maxlib, which is suspected to be the cause of occasional crashes.
dependencies: pd >0.37, zexy, maxlib
- netpd-server-reduced.pd
plain netpd-server without logging and logview functionality
dependencies: pd >0.37, zexy, maxlib
- netpd-server-tcpserver.pd
plain netpd-server without logging and logview functionality, based on the tpcserver external from mrpeach. this patch currently runs on netpd.org for testing purposes.
dependencies: pd >0.40, mrpeach/tcpserver, moocow/pdstring
netpd-server2
netpd is in the process of being reworked in order to straighten out some flaws (NOTE: put link to a general description of the idea of new netpd). therefore the server was rewritten to comply with the new system of netpd.
proxy
basically netpd-server2 acts as an OSC (Open Sound Control) proxy: it forwards incoming OSC packets to a set of different possible receivers. this model allows to address several hosts, while using only one connection: a bidirectional tcp connection between client running on the local host and the remote host running the netpd-server2 (as described here). incoming messages are forwarded according to the first field of the OSC address of an OSC packet. this field is omitted in the forwarded OSC message. OSC packets with no valid receiver are silently ignored.
list of valid receivers
-----------------------
/b broadcast: OSC packet is forwarded to all connected clients
/s server: OSC packet is forwarded to the server (or any additional server module)
/<socket> socket number: OSC packet is forwarded to the client with specified socket number.
there are some restrictions about the socket number format:
- it must be an integer (floats are ignored)
- it must not contain any other characters than digits from 0 -> 9
- it must not exceed 6 digits (due to pd's way of representing high numbers)
- it can contain preceding zeros as long as above requirements are met
due to this restrictions, the maximum number of clients is limited to 999'999.
modules
this server is intended to provide minimum functionality needed for a working setup. however, the functionality of this server can be expanded by modules. modules are patches, that are started within the same instance of pd as the server patch. the server patch provides a simple API, so that methods provided by modules can be called transparently. each module is addressed by the second field of the OSC address. if there is a module 'log' listening on '/log' on the server, it can be addressed from the client with '/s/log'.
methods of the server
the server patch provides its methods on '/server', respectively on '/s/server' (from the clients perspective).
list of server methods
----------------------
CLIENT /s/server/socket request the own socket number
SERVER /server/socket <socket> server sends this packet only to the requesting client
CLIENT /s/server/ip
SERVER /server/ip <ip address> the ip address is formatted as a list with four numbers
SERVER /server/num_of_clients <num_of_clients>
this message is broadcasted to all clients without being requested
(push)
download
you can get a copy of the current version here:
here a little testclient to illustrate how the new server works:
testing
an instance of this proxy server for testing purposes is running on netpd.org listening on the port 8003