--- In [email protected], sgp acs322000 <[EMAIL PROTECTED]> wrote:
> 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.

No it won't, but not only for that reason.   See below.


> > 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.

Hmm.  Don't know what that means.

WriteNamedPipe docs:
"This program creates a pipe by the name specified and waits for a
client to connect to the pipe. When a client connects, the message
is written and the program exits. The pipe is created as duplex and
in byte-mode. A client can connect with either read or read and
write permission."

In other words WriteNamedPipe creates a pipe as server, waits for a
client, then wrote to client. 

pipe plugin can write to _listening_ pipes, and listen for _writing_
clients.

Incompatible.


Why do you want to use  WriteNamedPipe?  If you want to communicate
with powerpro, ppBang and <powerpro.exe> <command to send> will do the
job.  Is there some reason you want yet another means to send to PP?

If so, I can rewrite WriteNamedPipe so that conforms to pipe
expectations.  Byte-mode transfers don't make much
sense to me in this context.  And PP is a natural server, always
present, so the current WriteNamedPipe which assumes a transient
client not very relevant.

No action for a few weeks though, gotta go do some work.

 
> > 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.

You can do that.


> 
> > 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

How does listener know when the sender has no more to send and wishes
to disconnect?  In other words, when does it destroy instances of pipe
"connect"?





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/
 



Reply via email to