previously on VL: vl-progress-report-4
the vivid blog reader already knows the drill: everything stays the same if you liked it just the way it was.
Specify remote host (IP address), a nice port number, connect some data and bang the send to let your UDP packets travel over the network. Or open a server to receive bytes arriving on the specified port. The only difference to vvvv you might see is, that here you also get infos about the sender of the packets via the Remote Endpoint output (which is an IP Address and a port)
same same for the TCP nodes: The client will try to connect to a server. And once the connection is established, you can send and receive bytes.
The TCP Server awaits incoming connections to talk to. The subtle difference here is the Tuple input, where you would expect the data pin. No one ever requested it, but now you can decide which packet should be sent to which client by specifying IP address and port together with the message. In case you still want to send the same packet to all of your clients, just set the address to 0.0.0.0 and port 0
so why did it take so long, what's the goodies behind that?
Unlike the monolithic networking nodes in vvvv you can peek inside the VL ones. The goal was modularizing on a much lower level to be able to provide the very basics as nodes for the patcher:
the cryptic one line description on msdn is: WebRequest makes a request to a Uniform Resource Identifier (URI). imho meaning you can do all sort of things related to http://, ftp://, and file://.
girlpower/VL/_Experimental/Async/AsyncTask.v4p features a very simple example of requesting the vvvv35.zip on this server and downloading it and saving it on your desktop.
The nodeset, however, features all the functionality required to do fully featured http communication: HEAD, GET, POST, PUT,..., status codes, media types, content encoding, credentials, etc,...
Conveniently the request/response communication is based on Streams which already was available in VL through the work on File IO, yay!
web nerds, give it a try and report what's missing!
the UDP and TCP nodes in vvvv are running nicely in the background without blocking the main process itself. same for the VL nodes, just that we (again) tried to come up with a very general and reusable way of implementing it in order to have it available to every patcher. so welcome to world parallel programming, visually!
this region implements the same pattern as Copier (Async), Writer (Async),... It is meant for long-running tasks which would block your main application otherwise.
Now you just bang the Restart pin and it will execute what every you patched inside the region in the background and hand over the result once it's finished. it shows you its status (if it's working at the moment) and you can cancel it midways. (we left out progress reporting in this release)
is the other region for parallelizing your nodes. you can think of it as a patch running it's own separated speed/mainloop: it computes the nodes it holds and starts again, no matter how long or short it takes. once (re)started it loops forever as fast as possible until cancelled or aborted (break) from within:
the result of the nodes inside the loop is pushed back to the main patch and you can collect a (possibly empty) spread of results on the output. it's a spread since we have no idea how many times the loop has been running while vvvv had one regular frame.
and the same principle is applied if you want to pipe things into that async running loop: data running into the data input of the region are queued and available inside the region asap.
hope you like what you read!
and again the reminder, that this is published as experimental, so possibly due to changes.
anonymous user login