メディアアートの世界でよく利用されるProcessing.
通信プログラムも使えますが、サーバサイドの待ち受けの仕方に独自のものがあるねので、調べてみました。
Processingは、draw()ループの中でクライアントからのリクエストを待つわけですが、フレームレートが変化したとき、クライアント側の動きはどのようになるのか確かめたいと思っていました。
環境: Processing3.3.5(Server), Curl/Bash(Client) / Windows 10
Server
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
import processing.net.*; Server s; Client c; void setup() { size(100, 100); background(204); stroke(0); frameRate(60); s = new Server(this, 80); } void draw() { print("."); c = s.available(); if (c != null) { if(c.available()>0){ String recv = c.readString(); String[] req = trim(split(recv, '\n')); String r = req[0].substring(0, 5); if(r.equals("GET /")){ println(req[0]); c.write("HTTP/1.1 200 OK\n"); c.write("Content-Type: text/html\n"); c.write("\n"); String[] u = split(req[0], ' '); c.write("OK:" + u[1] + "\n"); } c.stop(); } } } |
Client
1 2 3 4 5 |
#!/bin/bash for i in `seq 1 20` : do curl http://localhost/${i} done |
HTTPリクエストを投げると、OKの文字列とパスを返してくれるものです。
frameRateはSetup()のはframeRate()で設定します。
(フレームレート:一秒間に描画(draw)する数)
まずは60で、bashプログラムを実行してみます。
約1.5秒で20リクエストが終了しました。
(Client SocketException が発生する原因はよくわかりませんでした)
次にフレームレートを1にして実行すると20秒かかりました。
最後に、bashプログラムをもう一つコンソールを開いて同時に実行します。
結果は交互に受信して、時間も倍かかりました。
フレームレートが落ちるとクライアントは待たされるようです。
bash側の連続リクエストがそれほど速くないので、60フレームだとループの方がはやく、リクエストがないときは別の処理ができそうです。(.ドットを毎フレーム表示して確認)
自分で書いておいてなんですが、待ち受け側をサーバと呼んでしまいがちですが、Processingのようなアプリではちょっと違和感がありますね。(MincecraftもScratchもですが..)