r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Uniserve] Creating Uniserve processes

Graham
19-Oct-2008
[583]
silly me
Dockimbel
19-Oct-2008
[584x2]
exactly
...for the helper process (not you being silly) ;-)
Graham
19-Oct-2008
[586]
:)
PeterWood
19-Oct-2008
[587]
Graham: Have you consiered the alternative approach of calling a 
text-to-speech program on the client?


Of course, this facility is builtin to Mac OS.Google pointed me to 
this for other clients :
http://www.cstr.ed.ac.uk/projects/festival/download.html
Graham
19-Oct-2008
[588x2]
Peter, yes, but I'm not aware of such facility on Linux.
And there are some web services that provide much higher quality 
than MS's speech.
PeterWood
19-Oct-2008
[590]
Festival appears to run on Linux, BSD, Solaris and Wndows...only 
Mac seems to be missing from the list.
Graham
19-Oct-2008
[591x3]
Oh ..., I put Festival in the too hard basket long time ago :)
But really I was enquiring about the principle involved in running 
a blocking process on Uniserve.
I wonder how just opening a port to Cheyenne and inserting the command, 
and then closing immediately would work??
PeterWood
19-Oct-2008
[594]
I think I'll have to put that in my too hard basket :)
Dockimbel
20-Oct-2008
[595]
Closing just after sending command : should work.
DanielP
14-Dec-2008
[596]
Hello, how can I choose the name of a server (other than "localhost") 
?
Graham
14-Dec-2008
[597]
host file
Oldes
15-Dec-2008
[598]
( WINDOWS\system32\drivers\etc\hosts )
Oldes
18-Jan-2009
[599x3]
What would be the best way how to limit server's output bandwidth 
using Uniserve? For example if i would like to write a stream server.
I guess by starting Uniserve as uniserve/boot/no-loop and providing 
own forever loop, am I right?
And in the loop write only so much data, as needed into connected 
clients.
Dockimbel
19-Jan-2009
[602]
The forever loop is : wait [ ]. How can you provide your own one? 
Limiting bandwidth would require control of data sent per seconds 
from 'on-write UniServe's callback. That means storing a timestamp 
of last sent packet and calculating the length of next packet based 
on time passed from last sent packet and bandwidth limit.
Will
19-Jan-2009
[603]
maybe you can get what you want with iptables or ipfw (on os x it's 
ipfw)
Oldes
19-Jan-2009
[604x2]
So you think that using something like:
...
uniserve/boot/no-wait
forever [
	wait 0:0:1
	foreach-listener-write-enough-data-to-play-1s
]
...
is not good approach?

I think I cannot do it from 'on-write as this would require to have 
separate input for each listener, which I don't want.

What happens is I write on port which does not finished previous 
write?
Will... I want to make a private mp3 stream server to play music 
on a local network. So it must be solved on the server side... read 
only enough sound data from disk to play and distribute it to listeners. 
I have already the mp3 parser to get for example enough data to play 
during specified interval of time. Now it's just how to distribute 
it and don't send more data than is necessary  for the listeners.
Dockimbel
19-Jan-2009
[606]
I don't remember if WAIT is processing network events when called 
with a time! value. If it's not processing events, your writes would 
have to be in blocking mode, so sending data one after another.
[unknown: 5]
19-Jan-2009
[607]
I wouldn't think that wait would be working like that.  I think you 
can only use wait [] to process the wait-list.
Dockimbel
19-Jan-2009
[608]
UniServe would be then useless, because it couldn't work in async 
mode.
Oldes
19-Jan-2009
[609x2]
it should be wait [ 0:0:1]
I will test it anyway
Dockimbel
19-Jan-2009
[611]
Wait [ 0:0:1] won't work as you expect. You don't have any guaranty 
that it will exit from the loop every seconds. It depends on network 
activity. The time! value indicates a timeout duration from last 
network event.
Oldes
19-Jan-2009
[612]
Which events? Even the on-write events? Not being called in precise 
interval would not be a problem. I think.
Dockimbel
19-Jan-2009
[613x2]
For example, if you have, on average, one network event (port opening, 
packet coming, packet to be sent (async write),...) every 0.5sec, 
it's enough to delay the exit from your WAIT [ 0:0:1 ] for several 
seconds or even minutes.
As long as you get any event happening before a timeout occurs, you'll 
stay in the WAIT event loop.
Steeve
19-Jan-2009
[615x2]
what the prob ? if you do a wait [0.001] it should process one event 
at a time.
maybe wait [0] works too
Oldes
19-Jan-2009
[617]
Ah.. I see Doc, that is a problem.. so it looks I will have to write 
the data from 'on-write. Just will have to find out, how to make 
it synced, because I would like to have all listeners play the sound 
in the same moment. If it's possible.
Dockimbel
20-Jan-2009
[618]
WAIT [0] should return just after the first event is processed, but 
that's not the point. It's about being able to send the same amount 
of data every seconds.
Pekr
20-Jan-2009
[619x3]
how can you do it in terms of single process?
As long as you get any event happening before a timeout occurs, you'll 
stay in the WAIT event loop.

 - Doc - is it really correct? I am far from being guru here, but 
 it sounds strange - that would mean, that as far as there are events 
 coming, you are not allowed to quit wait, no? I think that 'wait 
 waits for either the event, or an timeout to occur. If there is any 
 kind of event on port in wait-list, 'wait return. It can either return 
 with first port with event, or, when using /all refinement, with 
 block of all ports, which have event available on them at the time 
 of return ...
but - you surely know what you are talking about, so I have to be 
wrong :-)
Dockimbel
20-Jan-2009
[622x3]
WAIT has many different behaviours depending on the passed argument.
When called with [ ] or [ integer! ], WAIT will process all ports 
stored in system/ports/wait-list. In that case, WAIT will block until 
:

- a timeout is specified and no more events are received for that 
timeout period
- an event returns a TRUE value.
Not sure about the WAIT [port1 port2 ...] case. I guess that it will 
process all events from system/ports/wait-list but will exit on first 
event received by port1, port2,...
Oldes
20-Jan-2009
[625x3]
just tried to add this before cheyenne starts:
do-events: does [
	forever [wait [0:0:1] print now/time/precise]
]
And from second console run:
loop 1000 [read http://localhost]


the result is, that it prints the time in every second while it serves 
the requests.
In the same time it was serving MP3 from modified micro-http service 
using something like:
    on-received: func [data][
		write-client rejoin[
			{ICY 200 OK} crlf
			{icy-name: LocalRadio} crlf
			{icy-genre: whatever} crlf
			{icy-url: http://127.0.0.1:811} crlf
			{content-type: audio/mpeg} crlf
			{icy-pub: 1} crlf
			{icy-br: 128} crlf 
			crlf
		]
		write-client path-to-mp3-file
	        close-client
    ]
And running my RebolBB with responses <16ms
Steeve
20-Jan-2009
[628]
So Doc was wrong, it's unusual...
Dockimbel
20-Jan-2009
[629]
Oldes: thanks for taking the time to test it. The correct behaviour 
of WAIT is the one you've described. I'm glad you've corrected me 
on that one. I'm pretty sure that I've run such tests with different 
results when working on UniServe five years ago. Maybe something 
changed in REBOL kernel since then or maybe my test script was just 
flawed. Nice to see that there's still something to learn from R2.
Janko
20-Jan-2009
[630]
wow, audio streaming in rebol and uniserve .. cool
NickA
21-Jan-2009
[631x2]
I need to learn more about thay!
thay -> that