World: r3wp
[!Uniserve] Creating Uniserve processes
| older newer | first last |
| BrianH 2-Mar-2008 [566] | You could take advantage of Uniserve's task dispatch and process management to do load balancing between LNS servers. |
| Graham 19-Oct-2008 [567x2] | Doc, what I want to do is do some text to speech using a 3rd party web service. I need to download the generated wave file and play it by inserting it into a sound port. The read would be blocking if I use sync read, and then playing it thru a sound port in my experience does interfere with async tcp. In a nutshell, is this sort of activity suitable for a task-master service .. and is there a simple sample of such a service? The task would be triggered from an RSP page |
Since any client could be accessing the cheyenne server, I want a response returned immediately so that it doesn't block the client. And the sound can be played later on ... | |
| Dockimbel 19-Oct-2008 [569] | So, if I understand correcty, you need to download a file on client side from a web server without blocking on the client side ? |
| Terry 19-Oct-2008 [570x2] | You can't send a response, then another and another unless you use Comet technologies |
Which means leaving the connection open.. not sure how Cheyenne would deal with this | |
| Graham 19-Oct-2008 [572x2] | I've got Univserve/cheyenne running on localhost. I want my client to ask uniserve to download a file using one of it's processes and then play it through a sound port. My client uses a http request and wants that to be non blocking ie. return immediately. The client may itself not be capable of doing an async request. |
eg. client => read http://localhost/speak.rsp?txt=helloworld speak.rsp <% data: read/binary http://somewebserivice/cgi-bin/to-wave?text=helloworld insert sound-port data %> <html></html> in this scenario the client has to wait for the response. How would one send the empty result back immediately, and then process the request so that the client is not blocked and where the client is incapable of an async read | |
| Dockimbel 19-Oct-2008 [574] | You can't send back a response to the client without ending the RSP processing. Uniserve is not loaded in helper processes, so you can issue async read requests. Is your client REBOL-based ? |
| Graham 19-Oct-2008 [575x3] | Just thinking of creating a general purpose app so not necesssarily |
So, I guess I just need to use call instead which is async and returns immediately | |
ie. don't wait for the result | |
| Dockimbel 19-Oct-2008 [578] | Right, you use LAUNCH or CALL. |
| Graham 19-Oct-2008 [579x2] | is there a way to get one of those helper processes to do this? |
ie. to run the call for me? | |
| Dockimbel 19-Oct-2008 [581] | Do it in your speak.rsp, it should be ok as long as your call/launch is not blocking. |
| Graham 19-Oct-2008 [582x2] | ahh... okay, since speak.rsp is already been run by one of those helper processes |
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 [615] | what the prob ? if you do a wait [0.001] it should process one event at a time. |
| older newer | first last |