Quantcast

LSL HTTP server is slow (part II)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

LSL HTTP server is slow (part II)

Jeff Kelley
 From part I, we know we can stuff commands from the outside world to
a LSL script at a decent rate. It's time to build something a little
bit more sexy than a Perl script.

A good choice of language is HTML + Javascript. Because we can build
pretty sophisticated UI's. And because we can fold the UI inside the
simulation world at no extra cost using MOAP.

Lets's rez a prim and put this script inside:
https://github.com/jeff-kelley/opensim-utils/tree/master/sliders/sliders.lsl

Copy the url from the chat window. Be careful not to include a leading space.

Now, head up to http://grid.pescadoo.net/sliders/

Full source code available at :
https://github.com/jeff-kelley/opensim-utils/tree/master/sliders/web

Install it on a web server, or just use my web page to test.


'Name' holds the name or UUID of an object. When entering a name
here, a call is made to a name-to-url resolver, and the result is
written in the 'URI' field. Think to it like a DNS.

The resolver is not included in this release. For now, bypass it
pasting the url (the one you copied from the chat window) into the
'URI' field of the web page.

Below is an array of sliders and buttons (Thanks John Judnich for the
original code) When moving them, a message name=value is sent to your
script.

The example script changes the prim's color. Param1 is red, Param2
green, Param3 blue. You catch the idea, this is just a demo app.
Everything that can be controlled by script (and that's a lot) can be
controlled from the outside world in real-time. You may want to
change my 20ms throttling (application.js, line 54).

Warning : I use JSONP to overcome the same-origin policy
(application.js, line 68 : $.getJSON). This may fail with some web
browser. If it don't work first, try another browser.

Let me know if it works.


-- Jeff

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Tom Frost
Hi,

Out of curiosity, how well does this scale? I remember in SL there was a
limit to the number of URL's a resident can have (38 from
http://wiki.secondlife.com/wiki/LSL_http_server#Resource_Limitations),
which implies that url's don't scale that well in SL. How does the http
server in opensim scale?

Gr,

Tom

On Thu, Jan 14, 2016 at 10:32:38PM +0100, Jeff Kelley wrote:

> From part I, we know we can stuff commands from the outside world to
> a LSL script at a decent rate. It's time to build something a little
> bit more sexy than a Perl script.
>
> A good choice of language is HTML + Javascript. Because we can build
> pretty sophisticated UI's. And because we can fold the UI inside the
> simulation world at no extra cost using MOAP.
>
> Lets's rez a prim and put this script inside:
> https://github.com/jeff-kelley/opensim-utils/tree/master/sliders/sliders.lsl
>
> Copy the url from the chat window. Be careful not to include a leading space.
>
> Now, head up to http://grid.pescadoo.net/sliders/
>
> Full source code available at :
> https://github.com/jeff-kelley/opensim-utils/tree/master/sliders/web
>
> Install it on a web server, or just use my web page to test.
>
>
> 'Name' holds the name or UUID of an object. When entering a name
> here, a call is made to a name-to-url resolver, and the result is
> written in the 'URI' field. Think to it like a DNS.
>
> The resolver is not included in this release. For now, bypass it
> pasting the url (the one you copied from the chat window) into the
> 'URI' field of the web page.
>
> Below is an array of sliders and buttons (Thanks John Judnich for
> the original code) When moving them, a message name=value is sent to
> your script.
>
> The example script changes the prim's color. Param1 is red, Param2
> green, Param3 blue. You catch the idea, this is just a demo app.
> Everything that can be controlled by script (and that's a lot) can
> be controlled from the outside world in real-time. You may want to
> change my 20ms throttling (application.js, line 54).
>
> Warning : I use JSONP to overcome the same-origin policy
> (application.js, line 68 : $.getJSON). This may fail with some web
> browser. If it don't work first, try another browser.
>
> Let me know if it works.
>
>
> -- Jeff
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Jeff Kelley
At 9:50 AM +0100 1/15/16, Tom Frost wrote:

>Out of curiosity, how well does this scale? I remember in SL there was a
>limit to the number of URL's a resident can have (38 from
>http://wiki.secondlife.com/wiki/LSL_http_server#Resource_Limitations),
>which implies that url's don't scale that well in SL. How does the http
>server in opensim scale?


Hi Tom.

In opensim, in a region with no url allocated, llGetFreeURLs() returns 100.

In a real app, you probably don't want to manage as many. Rather one,
and dispatch commands via chat or MessageLinked.


-- Jeff
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Tom Frost
Hi Jeff,

On Fri, Jan 15, 2016 at 03:45:50AM +0100, Jeff Kelley wrote:

> At 9:50 AM +0100 1/15/16, Tom Frost wrote:
>
> >Out of curiosity, how well does this scale? I remember in SL there was a
> >limit to the number of URL's a resident can have (38 from
> >http://wiki.secondlife.com/wiki/LSL_http_server#Resource_Limitations),
> >which implies that url's don't scale that well in SL. How does the http
> >server in opensim scale?
>
> In opensim, in a region with no url allocated, llGetFreeURLs() returns 100.
>
> In a real app, you probably don't want to manage as many. Rather
> one, and dispatch commands via chat or MessageLinked.

Thanks. Wouldn't dispatching commands coming in from http over chat and
MessageLinked make things slow again?

I must say, i've never considered using incoming http requests. The
in-world scripts I made that need interaction outside of the sim are
low-frequency and generally pull-based.

Curious to see though, where you're endeavours are going to lead :)

- Tom
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Jeff Kelley
At 10:21 PM +0100 1/15/16, Tom Frost wrote:

>Wouldn't dispatching commands coming in from http over chat and
>MessageLinked make things slow again?

MessageLinked and chat are fast enough. We are not targeting 200
events/sec. ~20/30 are enough for smooth control, that is no
perceivable discontinuity.

>I must say, i've never considered using incoming http requests.

Once upon a time, we had mail. Then we had XML-RPC. Finally, HTTP in.

In my opinion, HTTP is the most flexible of all when you want to
shuttle data in and out. The main pain is to track URL's (they change
each time the sim restarts). You need to register to a database via a
web service, and resolve names to changing URL's. Thus, an object can
call the resolver, get the URL of another object (possibly on another
grid) and initiate a direct communication.

Fun story : when I was scripting on a public grid, my objects were
inadvertently included in oar's then replicated onto other grids.
Suddenly, I was receiving registration requests from unknown grids.
Since that, I have included a remote kill feature.

>The in-world scripts I made that need interaction outside of the sim are
>low-frequency and generally pull-based.

I'm a real-time guy, so I was interested from the beginning to push
the limits. Years ago, I was using UDP and C# scripts to communicate.
I'm doing all over HTTP now.

>Curious to see though, where you're endeavours are going to lead :)

This is opensimulator, so we are probably going to simulate
something. Maybe a factory, a nuclear plant, an industrial process, a
physics experiment... We want things that work when we act on them.
And we want nice control panels, dont' we? The time of prim buttons
and xyText is over. Design in HTML and cast it inside opensim.



-- Jeff
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Melanie
Don't forget one very important thing: osMessageObject!

It's as fast as link messages but spans objects. I have made a club
lighting system that uses actual DMX hardware controllers and MIDI
controllers and send the data to inworld. Turns out the limiting
factor isn't the data pipeline but the speed at which ObjectUpdate
gets sent out. Also, streams are typically not in sync with events.
HTTP-in was plenty fast for this.

- Melanie

On 16/01/2016 02:03, Jeff Kelley wrote:

> At 10:21 PM +0100 1/15/16, Tom Frost wrote:
>
>>Wouldn't dispatching commands coming in from http over chat and
>>MessageLinked make things slow again?
>
> MessageLinked and chat are fast enough. We are not targeting 200
> events/sec. ~20/30 are enough for smooth control, that is no
> perceivable discontinuity.
>
>>I must say, i've never considered using incoming http requests.
>
> Once upon a time, we had mail. Then we had XML-RPC. Finally, HTTP in.
>
> In my opinion, HTTP is the most flexible of all when you want to
> shuttle data in and out. The main pain is to track URL's (they change
> each time the sim restarts). You need to register to a database via a
> web service, and resolve names to changing URL's. Thus, an object can
> call the resolver, get the URL of another object (possibly on another
> grid) and initiate a direct communication.
>
> Fun story : when I was scripting on a public grid, my objects were
> inadvertently included in oar's then replicated onto other grids.
> Suddenly, I was receiving registration requests from unknown grids.
> Since that, I have included a remote kill feature.
>
>>The in-world scripts I made that need interaction outside of the sim are
>>low-frequency and generally pull-based.
>
> I'm a real-time guy, so I was interested from the beginning to push
> the limits. Years ago, I was using UDP and C# scripts to communicate.
> I'm doing all over HTTP now.
>
>>Curious to see though, where you're endeavours are going to lead :)
>
> This is opensimulator, so we are probably going to simulate
> something. Maybe a factory, a nuclear plant, an industrial process, a
> physics experiment... We want things that work when we act on them.
> And we want nice control panels, dont' we? The time of prim buttons
> and xyText is over. Design in HTML and cast it inside opensim.
>
>
>
> -- Jeff
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

David Saunders-2
I been working with a few DJs, and written several boards and other stuff for them.   But on the things they noticed is the song board update faster then there stream does. :) I take that as a complement that I can get the boards updating faster then them listing to the stream.  I even added a trim command to them to "delay" the update.  If you DJ and listen to your output from you mixer and listen in the client as the same time you get an echo effect :) This is due to the time it takes to mixer->encoder -> stream server -> decoder -> listener.  This delay can be up to 15 sec depending on how everything is setup.  The only way to get a good sync with objects is to have the client proved the control with there own client. 



On Fri, Jan 15, 2016 at 8:09 PM, Melanie <[hidden email]> wrote:
Don't forget one very important thing: osMessageObject!

It's as fast as link messages but spans objects. I have made a club
lighting system that uses actual DMX hardware controllers and MIDI
controllers and send the data to inworld. Turns out the limiting
factor isn't the data pipeline but the speed at which ObjectUpdate
gets sent out. Also, streams are typically not in sync with events.
HTTP-in was plenty fast for this.

- Melanie

On 16/01/2016 02:03, Jeff Kelley wrote:
> At 10:21 PM +0100 1/15/16, Tom Frost wrote:
>
>>Wouldn't dispatching commands coming in from http over chat and
>>MessageLinked make things slow again?
>
> MessageLinked and chat are fast enough. We are not targeting 200
> events/sec. ~20/30 are enough for smooth control, that is no
> perceivable discontinuity.
>
>>I must say, i've never considered using incoming http requests.
>
> Once upon a time, we had mail. Then we had XML-RPC. Finally, HTTP in.
>
> In my opinion, HTTP is the most flexible of all when you want to
> shuttle data in and out. The main pain is to track URL's (they change
> each time the sim restarts). You need to register to a database via a
> web service, and resolve names to changing URL's. Thus, an object can
> call the resolver, get the URL of another object (possibly on another
> grid) and initiate a direct communication.
>
> Fun story : when I was scripting on a public grid, my objects were
> inadvertently included in oar's then replicated onto other grids.
> Suddenly, I was receiving registration requests from unknown grids.
> Since that, I have included a remote kill feature.
>
>>The in-world scripts I made that need interaction outside of the sim are
>>low-frequency and generally pull-based.
>
> I'm a real-time guy, so I was interested from the beginning to push
> the limits. Years ago, I was using UDP and C# scripts to communicate.
> I'm doing all over HTTP now.
>
>>Curious to see though, where you're endeavours are going to lead :)
>
> This is opensimulator, so we are probably going to simulate
> something. Maybe a factory, a nuclear plant, an industrial process, a
> physics experiment... We want things that work when we act on them.
> And we want nice control panels, dont' we? The time of prim buttons
> and xyText is over. Design in HTML and cast it inside opensim.
>
>
>
> -- Jeff
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Jeff Kelley
In reply to this post by Melanie
At 2:09 AM +0100 1/16/16, Melanie wrote:

>I have made a club lighting system that uses actual DMX hardware
>controllers and MIDI controllers and send the data to inworld. Turns
>out the limiting factor isn't the data pipeline but the speed at which
>ObjectUpdate gets sent out. Also, streams are typically not in sync
>with events. HTTP-in was plenty fast for this.

Here is a video dated May, 2011:

https://youtu.be/jBcnuPonKe4

(I finally managed to get a Youtube account since almost nobody can
read a raw MP4)

I was using UDP to stream commands in&out : No noticiable lag in both
directions. You may recognize an old version of MaxMSP, which make
easy to link any MIDI hardware (aka "control surface").

HTTP is lightweight and can lead to comparable performance. It
unlocks the HTML/AJAX technology at the remote end.

So no, the LSL HTTP server is not slow. It also allows inter-grid
communication. It's probably the most underused feature of scripting.


-- Jeff

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

Jeff Kelley
In reply to this post by David Saunders-2
At 12:08 PM -0500 1/16/16, David Saunders wrote:

>  I been working with a few DJs, and written several boards and other
>stuff for them.
>  But on the things they noticed is the song board update faster then
>there stream does.
>  I take that as a complement that I can get the boards updating
>faster then them listing
>  to the stream.  I even added a trim command to them to "delay" the
>update.  If you DJ
>  and listen to your output from you mixer and listen in the client
>as the same time you
>  get an echo effect :) This is due to the time it takes to
>mixer->encoder -> stream
>  server -> decoder -> listener.  This delay can be up to 15 sec
>depending on how
>  everything is setup.  The only way to get a good sync with objects
>is to have the
>  client proved the control with there own client.


Hi David.

Yes, audio streaming latency is a pain and breaks the action/result
loop in a bad way. You can't even try to compensate, since latency
differ from viewer to viewer. Your are never sure what your listeners
hear.

There is nothing we can do here. HTTP streaming is not real-time. RTP
is, but that's another story.

Happy DJ'ing (with delay).


-- Jeff
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LSL HTTP server is slow (part II)

David Saunders-2
In reply to this post by David Saunders-2
Well RTP are only good as the latency of the network they are on :)   
 
  

On Sat, Jan 16, 2016 at 9:17 PM, Jeff Kelley <[hidden email]> wrote:
At 12:08 PM -0500 1/16/16, David Saunders wrote:

 I been working with a few DJs, and written several boards and other stuff for them.
 But on the things they noticed is the song board update faster then there stream does.
 I take that as a complement that I can get the boards updating faster then them listing
 to the stream.  I even added a trim command to them to "delay" the update.  If you DJ
 and listen to your output from you mixer and listen in the client as the same time you
 get an echo effect :) This is due to the time it takes to mixer->encoder -> stream
 server -> decoder -> listener.  This delay can be up to 15 sec depending on how
 everything is setup.  The only way to get a good sync with objects is to have the
 client proved the control with there own client.


Hi David.

Yes, audio streaming latency is a pain and breaks the action/result loop in a bad way. You can't even try to compensate, since latency differ from viewer to viewer. Your are never sure what your listeners hear.

There is nothing we can do here. HTTP streaming is not real-time. RTP is, but that's another story.

Happy DJ'ing (with delay).



-- Jeff
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Loading...