| # | User | Message | Date |
| 720 | Endo | Problem solved. Thanks Doc. | 19-Dec 8:31 |
| 719 | Endo | "data" is somehow none.
The error happens in on-task-done event function: on-task-done: func [data /local valid out value ctype body headers s e][ either "HTTP" = copy/part data 4 [ ;<<<<<<<<<< ;--- Non Parsed Header output --- write-client data ][ ;--- Parsed Header output --- out: ctype: line: none | 17-Dec 1:02 |
| 718 | Endo | 17/12-2:59:31.9210-[HTTPd] Method: GET - resource: /show.cgi 17/12-2:59:36.0930-[uniserve] New client: 127.0.0.1 - 9799 17/12-2:59:36.0930-[uniserve] Calling >on-new-client< 17/12-2:59:36.0930-[uniserve] << Port: 1723, low-level writing: 896 17/12-2:59:36.1090-[uniserve] Calling >on-write-done< 17/12-2:59:36.1250-[uniserve] >> Port: 1723, low-level reading: 13 17/12-2:59:36.1250-[uniserve] Calling >on-received< with {^@^@^@^-} 17/12-2:59:36.1400-[uniserve] Calling >on-received< with "[ok none]" 17/12-2:59:36.1400-## Error in [uniserve] : On-received call failed with error: make object! [ code: 303 type: 'script id: 'expect-arg arg1: 'copy arg2: 'value arg3: [series! port! bitset!] near: [either "HTTP" = copy/part data] where: 'on-task-done ] ! 17/12-2:59:36.1710-[uniserve] Port closed : 127.0.0.1 17/12-2:59:31.9210-[HTTPd] Method: GET - resource: /show.cgi 17/12-2:59:36.0930-[uniserve] New client: 127.0.0.1 - 9799 17/12-2:59:36.0930-[uniserve] Calling >on-new-client< 17/12-2:59:36.0930-[uniserve] << Port: 1723, low-level writing: 896 17/12-2:59:36.1090-[uniserve] Calling >on-write-done< 17/12-2:59:36.1250-[uniserve] >> Port: 1723, low-level reading: 13 17/12-2:59:36.1250-[uniserve] Calling >on-received< with {^@^@^@^-} 17/12-2:59:36.1400-[uniserve] Calling >on-received< with "[ok none]" 17/12-2:59:36.1400-## Error in [uniserve] : On-received call failed with error: make object! [ code: 303 type: 'script id: 'expect-arg arg1: 'copy arg2: 'value arg3: [series! port! bitset!] near: [either "HTTP" = copy/part data] where: 'on-task-done ] ! 17/12-2:59:36.1710-[uniserve] Port closed : 127.0.0.1 | 17-Dec 1:00 |
| 717 | Endo | By the way, old HTTPd service (in 0.9.9 zip) runs well for HTML pages. But gives following error when I request show.cgi file: | 17-Dec 1:00 |
| 716 | Endo | Same for task-master service. There is "uniserve/shared/server-ports" in "on-started" event. server-ports block is defined if we use Cheyenne. I made just a few extra control then able to run task-master service without Cheyenne. But couldn't run HTTPd | 17-Dec 0:57 |
| 715 | Endo | HTTPd service in UniServe is getting integrated with Cheyenne. There are some words & paths about Cheyenne which is not present when I use HTTPd without Cheyenne. | 17-Dec 0:46 |
| 714 | Dockimbel | Feel free to ask. | 16-Dec 22:54 |
| 713 | Endo | Thanks a lot. I might have some questions while coding. I'm writting a SMS Send/Receive/Forward server & client. | 16-Dec 22:53 |
| 712 | Dockimbel | And for new features, have a look in Cheyenne's changelog. | 16-Dec 22:49 |
| 711 | Dockimbel | Exactly. You can also use the documentation from http://softinnov.org/rebol/uniserve.shtml | 16-Dec 22:48 |
| 710 | Endo | No official documentation, but change-log is enough I think, right? (And services/protocols in Cheyenne as examples) | 16-Dec 22:47 |
| 709 | Dockimbel | The one from Cheyenne package. | 16-Dec 22:46 |
| 708 | Endo | I've started using UniServe in a production, should I use the one comes with Cheyenne or UniServe-r099? | 16-Dec 22:39 |
| 707 | Dockimbel | Graham: merging both smtp servers codebase could be a good option and a way for Cheyenne to get 7-bit SMTP server support (which it is lacking currently, so classified as still "experimental"). | 27-Feb-11 19:06 |
| 706 | GrahamC | My frustration with the iphone is the cause of this enquiry | 25-Feb-11 0:35 |
| 705 | Kaj | Only one way to find out | 25-Feb-11 0:23 |
| 704 | GrahamC | I wonder how it would work to partner my smtp ( receiving server ) with the smtp ( sending ) functionality available in Cheyenne | 25-Feb-11 0:17 |
| 703 | Kaj | As Brian says, they're largely complementary. UniServe is mostly about the transport layer, while RebServices is mostly about the messaging layer | 19-Oct-10 18:30 |
| 702 | nve | ok thx, I'm going to go deeper in Uniserve. | 18-Oct-10 22:08 |
| 701 | Pekr | nve - R/S were never properly finished. And for R3, Carl has lighter network services in mind. I would not bet on R/S for now ... | 17-Oct-10 16:38 |
| 700 | BrianH | R/S is a network protocol, mostly used for RPC. Uniserve is an infrastructure you can use to build network protocols on. For instance, the Cheyenne web server is built on Uniserve. For that matter, at one point someone built an R/S implementation on Uniserve. | 17-Oct-10 16:28 |
| 699 | nve | Briefly, can someone tell me the difference between Uniserve and Rebol/Services ? | 17-Oct-10 15:49 |
| 698 | Barik | Looks like I should be doing append shared/client-list client instead. | 4-Feb-10 16:43 |
| 697 | Barik | For the "IRC" client, I'm not clear on how to build the list of ports in Uniserve for all connected users. On the on-new-client function, do I do something like append shared/client-list self? | 4-Feb-10 15:20 |
| 696 | Dockimbel | That's the main improvement that could be made internally in Cheyenne. Other external improvements could be to use a fast load balancer like nginx dispatching requests over several Cheyenne instances (over multiple machines), or building more advanced clusters where each node would be a Cheyenne server with session exchanging abilities between nodes. | 29-Jan-10 23:46 |
| 695 | Dockimbel | Improving Cheyenne/UniServe: adding multithreading could make it scale much higher with much lower memory footprint. Currently, the main process stabilizes around ~20MB after a few hundred requests and each worker process take ~15-20MB depending on the application and loaded 3rd-party librairies. So for a server script what would take 1s to complete, supporting 100 clients simultaneously would require today ~2GB of memory. This is huge. Carl stated recently that threads overhead is 1MB, so with multithreading support, the memory usage for such use case would drop to ~100MB, which is an order of magnitude lower (not mentioning the speed gains and code simplifications resulting from dropping TCP-based IPC). | 29-Jan-10 23:41 |
| 694 | Dockimbel | Thanks for the diagram, there's probably a few branches that I could add to Cheyenne for better HTTP standard support. | 29-Jan-10 23:17 |
| 693 | Janko | aha .. http://webmachine.basho.com/diagram.html .. it's horibble basically .. if I would create a webserver I would just make 200 and few errors, f* with the rest :) | 29-Jan-10 10:31 |
| 692 | Janko | hm.. I can't find that http diagram | 29-Jan-10 10:28 |
| 691 | Janko | uses callbacks too | 29-Jan-10 10:24 |
| 690 | Janko | this is manually improved ragel generated http parser http://four.livejournal.com/1033160.html | 29-Jan-10 10:24 |
| 689 | Janko | for example of mongrell .. you typically run multiple (like 5) mongrell servers with ruby behind a nginx.. cheyenne does all this by itself so cheyenne also uses multicore /cpu better than other dyn lang servers by default. I am just thinking outloud if there are any prospects to make cheyenne/uniserve even more blazing if needed in future. | 29-Jan-10 10:20 |
| 688 | Janko | Yes, surely parse can do it... I am just debating .. I am not sure if mongrell is really that awesome. I was thinking that speedwise the upper bound of the http server is determined by socket handling and http parsing probably? Meaning that even if you have everything in ram and prepared you can't serve more thatn that. Cheyenne has a *very* high upper bound for a dynamic language (I was many times expressing my surprise and getting 250 req/s was the reason I returned back to rebol with doing all webapps in it now). | 29-Jan-10 10:14 |
| 687 | Pekr | I think that parse is powerfull enough to handle such parsing task. But finding common patterns out there might be helpful ... | 29-Jan-10 10:05 |
| 686 | Janko | I saw some huge graph one time as "whole HTTP spec" .. it was huge, and worying how complex it looked .. I will try to find it | 29-Jan-10 10:04 |
| 685 | Janko | but for the starters it requieres worka and time to discover if it's even worth it | 29-Jan-10 10:04 |
| 684 | Janko | **if** you found it's worth it you could make callbacks in c .. collect the result and only return it to rebol as data | 29-Jan-10 10:03 |
| 683 | Janko | aja.. didn't look that far .. I thougth it parses given input and gives some result , but because result is complex callbacks might be nevesarry .. | 29-Jan-10 10:01 |
| 682 | Dockimbel | At first look, Ragel relies on callbacks on matched patterns, so not a good fit for R2. | 29-Jan-10 9:59 |
| 681 | Janko | yes, I imagine http to get fully officially right is a major pain | 29-Jan-10 9:59 |
| 680 | Janko | I mean more advanced usage of rebol's parse | 29-Jan-10 9:59 |
| 679 | Janko | ha , this is similar as more advanced rebol parse :) | 29-Jan-10 9:59 |
| 678 | Janko | http://vision-media.ca/resources/misc/ragel-examples -- look here .. maybe this is the specification find "Mongrel HTTP 1/1" | 29-Jan-10 9:58 |
| 677 | Dockimbel | Ah, thanks for the info, I'll check the parsing rules used (that's a real PIA to get it right *and* secure). For the speed concern, a PARSE-based solution shouldn't be much slower than a C parser. | 29-Jan-10 9:55 |
| 676 | Janko | http://www.zedshaw.com/essays/ragel_state_charts.html | 29-Jan-10 9:53 |
| 675 | Janko | http://www.complang.org/ragel/ | 29-Jan-10 9:53 |
| 674 | Janko | mongrel is a server for ruby .. but it has a open sourced http parser that is written in "ragel" which is engine that makes some fast and lightweigh C code out of state machine specification. it's known as to be very fast and very robust because of that ( I listened too much online video talks in my life ) ... I will try to find some links | 29-Jan-10 9:52 |
| 673 | Dockimbel | I've heard of Mongrel server. What's special with its http parser? | 29-Jan-10 9:50 |
| 672 | Janko | while I am throwing in these libraries .. have you heard for mongrel http parser ? | 29-Jan-10 9:49 |
| 671 | Dockimbel | It should be possible to integrate it in R3 by rewriting the network part of the host kit (if both licenses are compatible). | 29-Jan-10 9:48 |
| 670 | Janko | Aha .. cool .. | 29-Jan-10 9:48 |
| 669 | Janko | I also don't know. I suppose it would mean to change the rebol event/async handling with this. I know this would be a huge decision so I am not expecting any answer or anything.. just wanted to put into discussion | 29-Jan-10 9:47 |
| 668 | Dockimbel | I'm aware of libevent. Wrapping such lib in R2 would mean, at least, giving up on REBOL ports and REBOL's event loop. Quite a huge price to pay (UniServe couldn't be used with View apps, nor could receive system:// port events anymore). There's also the need to call REBOL function from the C side, which is not well supported in R2 (not even in R3...yet). | 29-Jan-10 9:47 |
| 667 | Pekr | Libevent were suggested for R3, to be incorporated, but Carl said, that event model was rewritten for R3, and that it is really good. IMO Uniserve is relying on R2 even mechanism, I am not sure how it could use libevent instead? But that is for gurus to consider .. | 29-Jan-10 9:40 |
| 666 | Janko | I am asking just out of curiosity and because it could mean aditional benefits for uniserve (which I am looking to use for sometihng now) and by that of course also cheyenne | 29-Jan-10 9:39 |
| 665 | Janko | One question Doc , I know you invested a tons of time info figuring out all thinks needed to make async sockets with rebol work so well, but.. did you ever consider using something like libevent ( http://www.monkey.org/~provos/libevent/ ) or libev ( http://software.schmorp.de/pkg/libev.html ) . These libraries are very popular with embeding in many languages ( and show outstanding benchmarks ) last few years after the C10K problem was formulated ( http://www.kegel.com/c10k.html ) | 29-Jan-10 9:38 |
| 664 | Dockimbel | In your Uniserve service, build a list of ports with every client connecting (on-new-client event). When required, walk through the list of ports and broadcast whatever you want to the selected ones (or everyone). See this Chat application server-side source as an example of how to achieve that (it's not an Uniserve service, but it's very close anyway) : http://cheyenne-server.googlecode.com/svn/trunk/Cheyenne/www/ws-apps/chat.r The resulting chat application is here : http://demo.cheyenne-server.org:8080/chat.html | 13-Jan-10 22:52 |
| 663 | Barik | Basically, I need a way to do client to client communications with Uniserve, much like say a chat server. | 13-Jan-10 15:35 |
| 662 | Barik | If I have a Uniserve service that I've created, and two clients (say, A and B) connect to this service, how can I have A send a message to B? | 13-Jan-10 15:34 |
| 661 | Will | What is distributed actors library? sounds interesting 8) | 21-Nov-09 2:14 |
| 660 | Janko | I was looking at uniserve today .. really nicely made .. especially if you know that uniserve is running cheyenne which runs so fast and well .. I will port my distibuted actors library to use uniserve | 21-Nov-09 0:14 |
| 659 | Graham | ( this group is not supposed to be private - made public ) | 26-May-09 23:30 |
| 658 | Graham | Has anyone written a IRC server in Uniserve? | 26-May-09 23:29 |
| 657 | Maarten | Yes, but that's not working - someting with async ports. I have something on top of Rugby that works, but it's too slow. | 21-Feb-09 21:48 |
| 656 | Janko | aha, I found this http://www.colellachiara.com/soft/Libs/chord.r | 21-Feb-09 19:17 |
| 655 | Janko | hm.. interesting.. is there any more info about it on web somewher? ( btw: I remember I played with Rugby 8-10 years ago when I was allround programming newbie, it looked like total magic to me) | 21-Feb-09 19:16 |
| 654 | Maarten | yes | 21-Feb-09 18:58 |
| 653 | Janko | Chord.. is this that discributted hash table or something else? | 21-Feb-09 18:26 |
| 652 | Maarten | Nenad, this may help you: http://www.colellachiara.com/soft/Libs/timers.r | 21-Feb-09 16:30 |
| 651 | Maarten | First ugby on Uniserve. Then Chord on top of that.... Chord on Rugby is already working. | 21-Feb-09 16:25 |
| 650 | Dockimbel | Stability maybe? ;-) | 20-Feb-09 18:49 |
| 649 | Pekr | btw - what is missing in R3 to start porting of Uniserve to R3? Higher level protocols? Or tasks? | 20-Feb-09 9:59 |
| 648 | Pekr | Maarten - what about Chord concept, is it still valid? Or is there anything better out there worth implementing? | 20-Feb-09 9:58 |
| 647 | Pekr | Rugby to the rescue! I always wanted general multiplexing architecture being part of REBOL natively, but then I also wanted simplicity of Rugby. Now I will get both? :-) | 20-Feb-09 9:57 |
| 646 | Maarten | No, this will be world domination ;-) | 20-Feb-09 8:29 |
| 645 | Graham | Is this convergence ? :) | 19-Feb-09 19:23 |
| 644 | Dockimbel | That feature is waiting for weeks to be implemented (need it for adding a mail relay agent to Cheyenne and for cron-like jobs scheduling), I'll give it some time this weekend. | 19-Feb-09 13:33 |
| 643 | Maarten | The rest will be porting transport and state machines on the server, but as Rugby already had a CGI interface it hould be simle to use the server with Cheyenne. | 19-Feb-09 9:04 |
| 642 | Maarten | The balloon goes up! I want to move Rugby's transport layer to Uniserve, or even better, Cheyenne. (http tunneling). For this to really work I only need to know if you have primitives for timers in the event loop (inside the 'wait): do-every time! [ code ] do-after time! [code] | 19-Feb-09 9:03 |
| 641 | Dockimbel | Right, controling bandwidth requires changing UniServe's internals, mostly in 'on-write handler. | 21-Jan-09 21:55 |
| 640 | Oldes | probably no.. just found it as you told me, that I should control the data from it. | 21-Jan-09 21:49 |
| 639 | Dockimbel | Btw, 'on-write is not disabled in UniServe, it's just no more directly called in that specific case. | 21-Jan-09 21:49 |
| 638 | Dockimbel | It was useful on client side to kickstart first packet sent to a server (kind of fast shortcut to avoid a round in event loop before sending the first packet), but I had more issues than benefits from it, so I left the code deactivated in case I would need it in future, but it looks like I could remove those lines. Do you have a need for it? | 21-Jan-09 21:47 |
| 637 | Dockimbel | Right, that was a workaround for a packet sending issue, but never had to reactivate it. | 21-Jan-09 21:42 |
| 636 | Oldes | 0.9.17 21/12/2004 { o Added 'on-write-done event. o 'on-write call in 'write-peer temporaly deactivated. o bugfix in 'open-port, custom port-id now correctly used. } | 21-Jan-09 21:40 |
| 635 | Oldes | ; --- temporary deactivated ;on-write port | 21-Jan-09 21:39 |
| 634 | Dockimbel | What makes you think that? | 21-Jan-09 21:28 |
| 633 | Oldes | on-write is dissabled in the recent versions. Why? | 21-Jan-09 20:59 |
| 632 | NickA | thay -> that | 21-Jan-09 5:20 |
| 631 | NickA | I need to learn more about thay! | 21-Jan-09 5:20 |
| 630 | Janko | wow, audio streaming in rebol and uniserve .. cool | 20-Jan-09 23:41 |
| 629 | Dockimbel | 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. | 20-Jan-09 22:55 |
| 628 | Steeve | So Doc was wrong, it's unusual... | 20-Jan-09 21:45 |
| 627 | Oldes | And running my RebolBB with responses <16ms | 20-Jan-09 21:43 |
| 626 | Oldes | 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 ] | 20-Jan-09 21:40 |
| 625 | Oldes | 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. | 20-Jan-09 21:37 |
| 624 | Dockimbel | 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,... | 20-Jan-09 11:33 |
| 623 | Dockimbel | 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. | 20-Jan-09 11:30 |
| 622 | Dockimbel | WAIT has many different behaviours depending on the passed argument. | 20-Jan-09 11:25 |
| 621 | Pekr | but - you surely know what you are talking about, so I have to be wrong :-) | 20-Jan-09 10:53 |
| 620 | Pekr | "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 ... | 20-Jan-09 10:53 |
| 619 | Pekr | how can you do it in terms of single process? | 20-Jan-09 10:49 |
| 618 | Dockimbel | 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. | 20-Jan-09 10:47 |
| 617 | Oldes | 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. | 20-Jan-09 0:15 |
| 616 | Steeve | maybe wait [0] works too | 19-Jan-09 23:52 |
| 615 | Steeve | what the prob ? if you do a wait [0.001] it should process one event at a time. | 19-Jan-09 23:49 |
| 614 | Dockimbel | As long as you get any event happening before a timeout occurs, you'll stay in the WAIT event loop. | 19-Jan-09 23:24 |
| 613 | Dockimbel | 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. | 19-Jan-09 23:21 |
| 612 | Oldes | Which events? Even the on-write events? Not being called in precise interval would not be a problem. I think. | 19-Jan-09 20:36 |
| 611 | Dockimbel | 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. | 19-Jan-09 18:25 |
| 610 | Oldes | I will test it anyway | 19-Jan-09 15:52 |
| 609 | Oldes | it should be wait [ 0:0:1] | 19-Jan-09 15:48 |
| 608 | Dockimbel | UniServe would be then useless, because it couldn't work in async mode. | 19-Jan-09 14:55 |
| 607 | ? | I wouldn't think that wait would be working like that. I think you can only use wait [] to process the wait-list. | 19-Jan-09 14:54 |
| 606 | Dockimbel | 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. | 19-Jan-09 14:53 |
| 605 | Oldes | 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. | 19-Jan-09 12:54 |
| 604 | Oldes | 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? | 19-Jan-09 12:49 |
| 603 | Will | maybe you can get what you want with iptables or ipfw (on os x it's ipfw) | 19-Jan-09 10:05 |
| 602 | Dockimbel | 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. | 19-Jan-09 10:00 |
| 601 | Oldes | And in the loop write only so much data, as needed into connected clients. | 19-Jan-09 2:01 |
| 600 | Oldes | I guess by starting Uniserve as uniserve/boot/no-loop and providing own forever loop, am I right? | 19-Jan-09 2:00 |
| 599 | Oldes | 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. | 19-Jan-09 1:49 |
| 598 | Oldes | ( WINDOWS\system32\drivers\etc\hosts ) | 16-Dec-08 0:35 |
| 597 | Graham | host file | 14-Dec-08 23:04 |
| 596 | DanielP | Hello, how can I choose the name of a server (other than "localhost") ? | 14-Dec-08 21:29 |
| 595 | Dockimbel | Closing just after sending command : should work. | 20-Oct-08 8:47 |
| 594 | PeterWood | I think I'll have to put that in my too hard basket :) | 20-Oct-08 0:05 |
| 593 | Graham | I wonder how just opening a port to Cheyenne and inserting the command, and then closing immediately would work?? | 19-Oct-08 23:48 |
| 592 | Graham | But really I was enquiring about the principle involved in running a blocking process on Uniserve. | 19-Oct-08 23:41 |
| 591 | Graham | Oh ..., I put Festival in the too hard basket long time ago :) | 19-Oct-08 23:40 |
| 590 | PeterWood | Festival appears to run on Linux, BSD, Solaris and Wndows...only Mac seems to be missing from the list. | 19-Oct-08 23:40 |
| 589 | Graham | And there are some web services that provide much higher quality than MS's speech. | 19-Oct-08 23:35 |
| 588 | Graham | Peter, yes, but I'm not aware of such facility on Linux. | 19-Oct-08 23:35 |
| 587 | PeterWood | 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 | 19-Oct-08 23:05 |
| 586 | Graham | :) | 19-Oct-08 22:03 |
| 585 | Dockimbel | ...for the helper process (not you being silly) ;-) | 19-Oct-08 22:02 |
| 584 | Dockimbel | exactly | 19-Oct-08 22:02 |
| 583 | Graham | silly me | 19-Oct-08 21:58 |
| 582 | Graham | ahh... okay, since speak.rsp is already been run by one of those helper processes | 19-Oct-08 21:58 |
| 581 | Dockimbel | Do it in your speak.rsp, it should be ok as long as your call/launch is not blocking. | 19-Oct-08 21:57 |
| 580 | Graham | ie. to run the call for me? | 19-Oct-08 21:51 |
| 579 | Graham | is there a way to get one of those helper processes to do this? | 19-Oct-08 21:51 |
| 578 | Dockimbel | Right, you use LAUNCH or CALL. | 19-Oct-08 21:48 |
| 577 | Graham | ie. don't wait for the result | 19-Oct-08 21:47 |
| 576 | Graham | So, I guess I just need to use call instead which is async and returns immediately | 19-Oct-08 21:46 |
| 575 | Graham | Just thinking of creating a general purpose app so not necesssarily | 19-Oct-08 21:46 |
| 574 | Dockimbel | 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 ? | 19-Oct-08 21:41 |
| 573 | Graham | eg.
client => read http://localhost/speak.rsp?txt=hello%20world speak.rsp <% data: read/binary http://somewebserivice/cgi-bin/to-wave?text=hello%20world 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 | 19-Oct-08 19:34 |
| 572 | Graham | 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. | 19-Oct-08 18:12 |
| 571 | Terry | Which means leaving the connection open.. not sure how Cheyenne would deal with this | 19-Oct-08 16:19 |
| 570 | Terry | You can't send a response, then another and another unless you use Comet technologies | 19-Oct-08 16:18 |
| 569 | Dockimbel | So, if I understand correcty, you need to download a file on client side from a web server without blocking on the client side ? | 19-Oct-08 14:15 |
| 568 | Graham | 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 ... | 19-Oct-08 9:34 |
| 567 | Graham | 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 | 19-Oct-08 9:32 |
| 566 | BrianH | You could take advantage of Uniserve's task dispatch and process management to do load balancing between LNS servers. | 2-Mar-08 16:30 |
| 565 | ? | Wouldn't LNS currently have the same problem as Uniserve with respect to mono-processing? | 2-Mar-08 16:30 |
| 564 | BrianH | I wonder if it would make sense to make some kind of a multi-LNS layer over Uniserve. | 2-Mar-08 16:29 |
| 563 | ? | I think that Doc has the most available and supported Async offering right now that can even quality for my needs. | 2-Mar-08 16:14 |
| 562 | BrianH | Of course. | 2-Mar-08 16:12 |
| 561 | ? | I do see the problem Brian. | 2-Mar-08 16:11 |
| 560 | BrianH | Not discouraging you, just warning you :) | 2-Mar-08 16:10 |
| 559 | BrianH | Paul, you'd still need to think about all of those concurrent consistency problems if you went multi-threaded. Without serialization of some form, concurrent use will still be an issue, whether you are using processes or threads. | 2-Mar-08 16:09 |
| 558 | ? | Thanks Doc. | 2-Mar-08 15:47 |
| 557 | Kaj | I'm currently integrating the UniServe software stack into Syllable Server | 2-Mar-08 15:43 |
| 556 | Dockimbel | In that case, you need to rely on slave processes, each one executing TRETBASE. This means that you have to set up a distributed architecture, think about disk-writing synchronization between slaves, caches consistency,... All these could be easier done if we had multi-threading support in REBOL. It can be done without, but it's more complex and much less efficient. | 2-Mar-08 10:07 |
| 555 | ? | I would most likely have a lot of that going on with TRETBASE since the searches could take some time to produce results. | 2-Mar-08 0:37 |
| 554 | Dockimbel | To determine if you can leave the work inside the callback, just do some simple maths. E.g., if a request needs 50ms to be processed, that means that your server cannot do more than 20req/s. So it also depends on the load your server need to handle. | 1-Mar-08 23:59 |
| 553 | Dockimbel | So, you should be concerned about not doing heavy computation inside network event callbacks (like in 'on-received). If longer processing is needed, you should use the task-master service in Uniserve to send the request to a slave process (this has also the advantage of fully using the power of modern multicores processors). | 1-Mar-08 23:56 |
| 552 | Dockimbel | The main process (Uniserve process) should only do minimal work in processing port events so that other events can be processed in a short delay, giving the feeling of multitasking with several clients. | 1-Mar-08 23:51 |
| 551 | Dockimbel | Cheyenne uses the latest Uniserve's version. There's no special version of Uniserve for Cheyenne, so it's mono-thread. Uniserve also brings IPC between several slave processes using the task-master protocol (part of Uniserve, used in Cheyenne to run CGI and RSP scripts). | 1-Mar-08 23:49 |
| 550 | ? | Doc, does the Cheyenne version of Uniserve also have the mono-thread execution. If so, what should I be concerned about with regard to blocking? | 1-Mar-08 18:46 |
| 549 | Graham | Not yet ..but wanting to make sure that forks are folded back in :) | 27-Feb-07 18:31 |
| 548 | Oldes | graham: what I know, my postgres driver changes are not in the original version. At this moment I'm not using it as I even don't have postgres installed. Do you need it? | 27-Feb-07 10:50 |
| 547 | Pekr | hehe ... well, they are mostly MS based - tried their website and I got some aspx Microsoft db OLE provider error. Will have to talk to guys a bit :-) | 26-Feb-07 20:30 |
| 546 | Graham | If you're going to head IT services at this new company .. perhaps you could get someone to write this :) | 26-Feb-07 20:15 |
| 545 | Pekr | Well, hmm, why not, right? | 26-Feb-07 20:04 |
| 544 | Pekr | :-) How would it be usefull? | 26-Feb-07 20:04 |
| 543 | Graham | not if someone uses uniserve to write a driver :) | 26-Feb-07 19:53 |
| 542 | Pekr | hmm, wrong channel, sorry... | 26-Feb-07 19:50 |
| 541 | Pekr | eh? I thought that Firebird is being regarded being one of the best open-source offerings? No driver documented? Strange - each language except the Rebol has driver, so how they did it? | 26-Feb-07 19:50 |
| 540 | Graham | there is a client java module in CVS | 26-Feb-07 19:32 |
| 539 | Graham | I asked a year ago on the developer list .. they said, don't even think about it! | 26-Feb-07 19:28 |
| 538 | Maxim | maybe someone else did this and documented it? somewhere on the net... just thinking loud... | 26-Feb-07 19:28 |
| 537 | Graham | Or, to try and reverse engineer the protocol from another product | 26-Feb-07 19:27 |
| 536 | Graham | It has an undocumented tcp protocol .. so for Linux, there is no option but to move to something else | 26-Feb-07 19:27 |
| 535 | Pekr | Graham, btw., what would be needed for Rebol FireBird support? Does it use typical tcp scheme as mySQL e.g.? This week I met with two ppl using FireBird, and there seem to be no answer from Rebol part. Well, maybe ODBC, but that is not free ... | 26-Feb-07 19:24 |
| 534 | Graham | off topic oldes, but are your postgres driver fixes folded back into the offficial driver ? | 26-Feb-07 19:20 |
| 533 | Oldes | Yes, but if you know how works server, you should know client as well:] | 26-Feb-07 19:11 |
| 532 | Graham | I'm looking more for client than server :) | 26-Feb-07 19:10 |
| 531 | Oldes | but at this moment have other things to do | 26-Feb-07 19:05 |
| 530 | Oldes | maybe I could try to rewrite it | 26-Feb-07 19:04 |
| 529 | Oldes | I have somewhere testing script (not for uniserver) working as simple ftp server. | 26-Feb-07 19:04 |
| 528 | Dockimbel | Never really investigated deeply such construction, but at first look, I don't see any issue doing that. | 26-Feb-07 19:03 |
| 527 | Dockimbel | It would require to control a "data port service" from a "command port service". | 26-Feb-07 19:00 |
| 526 | Dockimbel | Not yet, but I would like to add one. | 26-Feb-07 18:58 |
| 525 | Graham | Or, at least an example of a uniserve client copes with using a command and a data port. | 26-Feb-07 18:56 |
| 524 | Graham | Is there a ftp client for uniserve? | 26-Feb-07 18:56 |
| 523 | Graham | He wouldn't drink Jaime's free beer! ... | 14-Feb-07 2:41 |
| 522 | Pekr | Rebolek - that is for sure! | 13-Feb-07 21:18 |
| 521 | Rebolek | so if we bring some czech beers, we can probably get whole source code? ;) | 13-Feb-07 19:57 |
| 520 | Henrik | "after several beers last year in Paris, Carl told me that..." oh, so that's how it works! pardon me, I couldn't help it. :-) | 13-Feb-07 18:40 |
| 519 | Dockimbel | About server-side SSL : after several beers last year in Paris, Carl told me that the ssl:// scheme could be turn to work as server-side with just the right flag set (IIRC, was about setting the right "direction" in encryption), then you "just" have to implement server-side HTTPS protocol to support it fully. I've since that, tryed several times to get the info about the "magic flag" from Carl, without success. So I've prepared several dozens bottles of beer to be sure to get the info from him at the next DevCon ;-). | 13-Feb-07 18:33 |
| 518 | Maxim | exactly the kind of snooping I'd add too :-) | 8-Feb-07 21:50 |
| 517 | Oldes | At the beginning I modified it a little bit to better print out urls and to save favicon files if found while browsing:) | 8-Feb-07 21:50 |
| 516 | Maxim | hum... and I was just wishing a stable proxy was available in rebol last week for some testing... thanks! for the info. | 8-Feb-07 21:49 |
| 515 | Oldes | The source is in %services/proxy-http.r | 8-Feb-07 21:47 |
| 514 | Oldes | yes, and it's the best Rebol proxy I used. Just: uniserve/boot/with [services [proxy-http] protocols [http]] | 8-Feb-07 21:46 |
| 513 | Maxim | hum... uniserve can work as a proxy ? | 8-Feb-07 21:37 |
| 512 | Oldes | Must say, that I'm all day using the proxy service from the latest uniserve and have no problems with it. It's fast enough even when streaming videos:) It's quite fun to watch what files are transfered while surfing. | 8-Feb-07 21:22 |
| 511 | Maxim | (and apache is good at handling thousands of requests without crashing) | 8-Feb-07 17:32 |
| 510 | Maxim | it also allows us to spread connections over many machines/threads virtualise the port and all that nice stuff without actually having to code it. | 8-Feb-07 17:31 |
| 509 | Maxim | If I had time I would have done it much before, but we ended up using apache and a reverse proxy setup... and that works really well. | 8-Feb-07 17:30 |
| 508 | Mchean | do i smell a competition? | 8-Feb-07 17:29 |
| 507 | Maxim | all the actual core needs are within... its just a question of reading the rfc (or implementation guides, or books) and using the encryptions funcs within REBOL... but I'll agree its not for the faint of heart... I've read a lot about server-side ssl implemtation a few months ago and its quite laborious. But still doable. | 8-Feb-07 15:43 |
| 506 | Ladislav | (you can implement it in REBOL) | 8-Feb-07 14:52 |
| 505 | Ladislav | :-) | 8-Feb-07 14:52 |
| 504 | Ladislav | close but no cigar again | 8-Feb-07 14:52 |
| 503 | Graham | let me rephrase that .. no one outside of RT and their contractors know how to do this. | 8-Feb-07 8:33 |
| 502 | Ladislav | "Rebol can't do server side SSL" - close but no cigar, actually, it is not that hard | 8-Feb-07 8:16 |
| 501 | Graham | So, without server side SSL, Cheyenne can't do https .. unless it's thru stunnel. | 8-Feb-07 1:28 |
| 500 | Graham | Rebol can't do server side SSL ... Carl thought it could by changing a flag, but it does not work when it was tested. | 8-Feb-07 1:28 |
| 499 | Graham | Sessions are broken in cheyenne. Basically session data from one client ends up as session data in another :( | 8-Feb-07 1:27 |
| 498 | BrianH | Reading is client-side SSL. | 7-Feb-07 19:54 |
| 497 | Oldes | ok... doc' seems to be online now, as he emailed me almost immediately: I'm aware of this problem (cgi and paths). It's because the encap-fs system is not correctly supported in this version of UniServe (it's ok in the Cheyenne package). I didn't fixed it because, with the release of Cheyenne, I'm not sure to keep the CGI support for the HTTPd service in the UniServe package. I may just provide a static HTTPd server with hooks to extend it or embed it in user applications. v1 of UniServe have to be very easy to embed in any app (that's one of main goals). | 7-Feb-07 19:52 |
| 496 | Henrik | well, command can read https pages...? | 7-Feb-07 19:52 |
| 495 | BrianH | I don't know how it would have HTTPS server support, even with /Command. I thought /Command only has SSL client support. | 7-Feb-07 19:51 |
| 494 | Oldes | I don't know how it's with https, I don't have /command | 7-Feb-07 19:49 |
| 493 | BrianH | You mean HTTPS? | 7-Feb-07 19:48 |
| 492 | Oldes | the chayenne is just encrypted uniserve | 7-Feb-07 19:47 |
| 491 | Oldes | there is file %libs/cookies.r so one can take a look at it, if needed | 7-Feb-07 19:46 |
| 490 | BrianH | Surely you are not surprised that Doc would disappear abruptly? He seems to have even less time than I do. | 7-Feb-07 19:46 |
| 489 | Pekr | BrianH - of course if you don't need sessions, httpd is probably working well. I just did not understand the Cheyenne release. The simple demo did not work. There is a demo with screen divided into something like 4x4 subwindows (frames), and most of them times out. Doc told me session layer is about to be rewritten, then no word from him for another few months | 7-Feb-07 19:43 |
| 488 | Oldes | I don't know what is with sessions. The uniserve seems to pretty good to me. I'm using it. And I think that Doc is still Reboling, probably just don't have so much time. | 7-Feb-07 19:40 |
| 487 | BrianH | Do you mean that sessions are non-working, or that there is something about non-working sessions that makes HTTP (a stateless protocol that wouldn't normally need sessions) not work? | 7-Feb-07 19:34 |
| 486 | Pekr | is Doc going to be back on Uniserve or Chayanne? Without fixed sessions it is mostly non working httpd server | 7-Feb-07 19:30 |
| 485 | Oldes | Yes, we had a short electronic contact :-) In this archive are the proxy and httpd services working without need of changes, the cgi test seems to give me an error so probably this will need some fix. | 7-Feb-07 19:22 |
| 484 | Pekr | btw - what fixes it needs? | 7-Feb-07 19:03 |
| 483 | Pekr | he is in contact with you? | 7-Feb-07 19:03 |
| 482 | Oldes | I've got this newer Nenad's version of UniServe http://box.lebeda.ws/~hmm/rebol/UniServe-r0991.zip (but as he said - beware, it needs several fixes and updates to become a 1.0 candidate) | 7-Feb-07 17:29 |
| 481 | Oldes | and I'm not using most of the files. (At least now) | 30-Jan-07 21:24 |
| 480 | Oldes | as the one above | 30-Jan-07 21:22 |
| 479 | Oldes | it works, but you have to do some small changes:-) | 30-Jan-07 21:22 |
| 478 | Pekr | so new version, 0919 does not work s is? | 30-Jan-07 21:21 |
| 477 | Oldes | I'm slowly moving forward:) after a few hours I almost have what I already had but using new uniserve:) | 30-Jan-07 21:14 |
| 476 | Oldes | This was quite important difference as my scripts were still using response (so I was getting result = none) | 30-Jan-07 21:11 |
| 475 | Mchean | so the project - moving forward - contains encapped modules? | 30-Jan-07 21:10 |
| 474 | Pekr | but 0.919 is provided with no documentation ... what is the difference then? | 30-Jan-07 21:08 |
| 473 | Oldes | hmm.... maybe if someone was using uniserver 0.9.9 and want to upgrade, there was important change - instead of module/response there is now module/result | 30-Jan-07 21:07 |
| 472 | Oldes | so what is here is Cheyenne in some unfinished state | 30-Jan-07 19:54 |
| 471 | Oldes | and if you look into cgi code in the UniServe archive, you can see, it identifies itself like soc/server-software: "Cheyenne/1.0" | 30-Jan-07 19:53 |
| 470 | Oldes | ech.. no, the compression should be in version 1.0 | 30-Jan-07 19:49 |
| 469 | Oldes | (not just httpd as it is able to do for example bzip2 compression so it probably needs some libs) | 30-Jan-07 19:48 |
| 468 | Oldes | Yes, the encapped part is the httpd service. You can see, that in Cheynne archive there is a little bit newer uniserve engine - 0.9.20 | 30-Jan-07 19:45 |
| 467 | Pekr | and do we have access to that httpd source? Cheyenne is encapped, no? | 30-Jan-07 19:29 |
| 466 | Oldes | Yes, the most recent version is newer httpd service which is called Cheynne :) | 30-Jan-07 19:27 |
| 465 | Pekr | I tried to contact him few days ago, and asked him for some more recent version. I somehow believe, that if he really uses it for his own stuff, he has to have some things fixed already :-) | 30-Jan-07 19:19 |
| 464 | Oldes | he just gave us some sources to play with | 30-Jan-07 19:17 |
| 463 | Oldes | it's not realease | 30-Jan-07 19:17 |
| 462 | Pekr | Later on he told me session handling is going to be rewriten, but then he left scene for another few months probably :-) | 30-Jan-07 19:17 |
| 461 | Oldes | At least I use it for such a scenario, which takes more than 10secs to process | 30-Jan-07 19:17 |
| 460 | Pekr | yes, but its session support sucks. I really don't understand, how Doc could release it, as it miserably fails. Have you tried multiple pane demo? | 30-Jan-07 19:16 |
| 459 | Oldes | Pekr: and if you need to process something which will take 10secs, Uniserve should be good in that. | 30-Jan-07 19:16 |
| 458 | Oldes | And don't forget, that Chayenne is made on Uniserve, it will be probably some more uptodate version:-) | 30-Jan-07 19:14 |
| 457 | Pekr | Uniserve is imo kind of engine we SHOULD adapt and include in the core. In the case of R3, using native R3 tasking ... | 30-Jan-07 19:14 |
| 456 | Pekr | Maarten later on introduced so called "green threading" (?), so you can divide your exposed function functionality in several or many parts, to get better granularity. Then he introduced chaining- so that e.g. main Rugby process could become kind of proxy, and forward (chain) request to other instance. But then there were some problems iirc and Maarten left its development. | 30-Jan-07 19:13 |
| 455 | Oldes | Pekr: I'm using uniserve as well for some time, but version 0.9.9 I found some time to look at the version 0.9.19 now so I'm examining it, and must say, that's just a quick pack of some files. | 30-Jan-07 19:13 |
| 454 | Pekr | Mchean - In the past I really loved Rugby - if you want to start with something, and learn something (RPC), it is really a good choice (Rugby). Very simple to use. What I did not liked was - its lack of asynchronicity. E.g. in Rugby you select your function of exported (so callable over the tcp/ip network). But if such function does something for 10secs, then all Rugby is blocked and it is not able to accept further requests. | 30-Jan-07 19:11 |
| 453 | Pekr | Oldes - what does your task master fix fixes particularly? | 30-Jan-07 19:09 |
| 452 | Pekr | That all sounds really strange, as Doc was claiming they use Uniserve in production for several customers or so, for quite some time ... | 30-Jan-07 19:09 |
| 451 | Oldes | and still have some problems... | 30-Jan-07 18:37 |
| 450 | Oldes | I just started:) | 30-Jan-07 18:36 |
| 449 | Graham | Oldes, why don't you release a fixed version ? | 30-Jan-07 18:33 |
| 448 | Oldes | And there is another bug in the UniServe0919 - there should be this in the file %services/task-master/task-handler.r (the [not value?] check is not enough): if any [not value? 'uniserve-path none? uniserve-path] [uniserve-path: what-dir] if any [not value? 'modules-path none? modules-path] [modules-path: dirize uniserve-path/modules] if any [not value? 'uniserve-port none? uniserve-port] [uniserve-port: 9799] | 30-Jan-07 18:20 |
| 447 | Mchean | thanks - i will look at that | 30-Jan-07 18:05 |
| 446 | Oldes | for example with this one http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=webserv.r | 30-Jan-07 18:04 |
| 445 | Oldes | I'm not sure if you should not start with some older server which are not async | 30-Jan-07 18:02 |
| 444 | Mchean | to learn about web servers, and rebol commands | 30-Jan-07 18:00 |
| 443 | Oldes | I started with uniserve 0.9.9 which is stable enough for me. | 30-Jan-07 18:00 |
| 442 | Oldes | what kind of learning? | 30-Jan-07 17:58 |
| 441 | Mchean | just a learning tool | 30-Jan-07 17:58 |
| 440 | Oldes | I don't know, I never used Rugby and don't know what you want to do:) | 30-Jan-07 17:57 |
| 439 | Mchean | ok thanks - do you think Rugby might be a better choice? | 30-Jan-07 17:56 |
| 438 | Oldes | the file is probably not in the best shape as there are some probes which are probably because of debugging which was Doc making at the moment when he gave it here | 30-Jan-07 17:55 |
| 437 | Oldes | you can also change the port you are listening - for example to 8080 | 30-Jan-07 17:53 |
| 436 | Oldes | just go to services/HTTPd.r file and edit the prefs | 30-Jan-07 17:52 |
| 435 | Mchean | my purpose is to educate myself about servers using Uniserve as a starting point | 30-Jan-07 17:51 |
| 434 | Mchean | hmm... maybe that's not a good expectation then | 30-Jan-07 17:51 |
| 433 | Mchean | Not really, just trying to get the out-of-box experience | 30-Jan-07 17:50 |
| 432 | Oldes | And if you are using the Uniserve from the link above, you should know, that it's just a shapshot from doc's folder so you have to for example edit some files - for example the default prefs of the HTTPd as they are leading into files which don't exists. | 30-Jan-07 17:50 |
| 431 | Oldes | do you really need all the protocols? If not, you can start uniserve using this way: do %uni-engine.r uniserve/verbose: 5 uniserve/boot/no-loop/with [ protocols [irc] services [flashd task-master httpd] ] ;do whatever here do-events | 30-Jan-07 17:43 |
| 430 | Mchean | yes, i think im making progress thanks for the help | 30-Jan-07 4:02 |
| 429 | Graham | does the binary work for you? | 30-Jan-07 1:41 |
| 428 | Mchean | I figured out how to stop the service tying up the 80 port , When i run this is what I get: >> do %/c/temp/rebol/uniserve/uni-engine.r == true >> uniserve/boot [uniserve] Async Protocol Admin loaded [uniserve] Async Protocol DNS loaded [uniserve] Async Protocol FastCGI loaded [uniserve] Async Protocol HTTP loaded ** Script Error: change expected series argument of type: series port ** Where: install-plugin ** Near: change pos/2 new | 30-Jan-07 1:31 |
| 427 | Mchean | scary how many open ports i have for processes i can't id | 29-Jan-07 23:07 |
| 426 | Mchean | It turns out I have a inetinfo service running which locks that port. Its used in IIS but since I'm not running it I'm not sure what is using this process, and killing it doesn't work, as it keeps coming back. I will have to investigate using another port | 29-Jan-07 22:54 |
| 425 | Mchean | i found this also on a suggestion from a friend: http://www.hijackfree.de/en/ | 29-Jan-07 20:04 |
| 424 | Pekr | netstat -an | 29-Jan-07 19:39 |
| 423 | Graham | try this http://www.microsoft.com/technet/sysinternals/utilities/TcpView.mspx | 29-Jan-07 19:26 |
| 422 | Graham | netstat will tell you that 80 is open | 29-Jan-07 19:21 |
| 421 | Graham | there are windows utilities to see what ports are opened and by what. | 29-Jan-07 19:16 |