entropyreduction wrote: > > Okay, first problem: pipe plugin creates pipe using flavour > PIPE_TYPE_MESSAGE, not PIPE_TYPE_BYTE. If it's needed I may > be able to add a parameter to the listen_on service to make it > either create byte or message pipe types. Lemme know if you want it. > Byte-oriented is less appropriate IMO: communications to PP will > always be small packets of info (command, variable value), not a > continuous byte stream. >
sounds like unless you do make this change writenamedpipe won't talk to your plugin. please make this change. > Also: if you run pipe.listen_on, _it_ creates a named pipe, and waits > on input. > > I'm not sure that's gonna work. My process has blocked waiting for > someone to do a WriteFile to me; WriteNamedPipe has created a > pipe and is hung, waiting for someone to execute a ReadFile. writenamedpipe will create its pipe only when a compatible pipe isn't there already. If your plugin can create a compatible pipe, then writenamedpipe will proceed immediately to writing into it and exit. > > Incompatible models, I think. God knows what's happening if they've > both created pipes with exactly same name, but it's gotta be ugly.... > In my test, in spite of the incompatible modes, writenamedpipe never blocked. it simply pretended to write and exited. but your plugin didn't seem to receive any data. > About having to do waits: my sample scripts e.g. > pipePluginTestScriptToSelf.powerpro > > do a 3000 msec wait.for between send_to's. That's mainly cause it > was a handy number when debugging. The script works fine if > I remove the waits. fire off many consecutive writes in a loop and see if it can sustain them. > > The method I'm using for handling pipes will inevitably have overhead: > server waits on a message, receives message, _then disconnects > from the client_, leaving itself available for messages from other > clients. > well, all methods have overhead, even when written in assembly language. the point is how available is the listener, 99.9% of the time vs 0.01% or somewhere reasonable in between. > That means if you do a series of send_to's from the same client, > the pipe connections will have to be remade for each one. > > A classic way to improve throughput is for the listener to respond to > any attempt to connect by creating another pipe, that will be > dedicated to that particular client. I could implement that; it would > mean adding new services (connect/disconnect). Let me know if you > need it. I'm no sure new services are needed, as long as the plugin can handle multiple pipes. what do you think of this pseudoscripts: ACCEPT_LOOP: ; for listener block reading from pipe "accept" ; all senders write to "accept" once dedicatedpipename=make_new_name_for_it write (no block) to pipe "connect" dedicatedpipename start dedicated listener on pipe dedicatedpipename ; new thread goto ACCEPT_LOOP CONNECT: ; for any sender block writing to pipe "accept" "hi" block reading dedicatedpipename from pipe "connect" ; now use dedicatedpipename to read/write to dedicated listener Attention: PowerPro's Web site has moved: http://www.ppro.org Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/power-pro/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
