NamedPipe Asynch example

Forums for specific tips, techniques and example code
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

NamedPipe Asynch example

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:23 pm

by jadenews.jade.co.nz >> Wed, 3 May 2000 23:22:32 GMT

Has anyone got a piece of code illustrating use of listen, read, write & close asynch methods for NamedPipe? I am fiddling around with asynchronous comms between jade and another app, and I must say that Jade documentation is a bit shy on this subject.
Any example would be really helpful.

Cheers,

Hido

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: NamedPipe Asynch example

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:24 pm

by Darrell Duniam >> Thu, 4 May 2000 1:44:46 GMT

Unfortunately, the JADE documentation is "a bit shy" on most subjects - I've made the comment before, that much of the Help is most meaningful if you are already familiar with the subject of interest, which kinda defeats the purpose :-(

Anyway, I have some bits and pieces which may be of interest to you. Reply to me if you're interested.

darrell.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: NamedPipe Asynch example

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:24 pm

by Wilfred Verkley >> Sat, 6 May 2000 2:44:01 GMT

Its not very hard. I wrote a simple web framework to replace the jade stuff. The ISAPI DLL i wrote talked to jade using a named pipe (just like the jade's jadehttp.dll). I have an object in Jade called "JadeWebManager" with a "myPipe" reference to a NamedPipe.

The actual name of the pipe device you create is "\\.\PIPE\" + the name you define on the NamedPipe object. This little bit of info is important if your external program is VB or C++ and is using win32 calls to talk to jade.

Here are the three basic methods :

init () updating;
// begin listeningbegin

myPipe.name := jadeWebApp.name;
myPipe.listenAsynch (self, "listenCallback");
end;

listenCallback (pipe: NamedPipe) updating, protected;
// get the response and send back the request, then close the connection vars
request : Binary;
response : Binary;begin

request := pipe.readBinary (0);
response := execute (request); // do the processing
pipe.writeBinary (response);
epilog
pipe.closeAsynch (self, "closeCallback");
end;

closeCallback (pipe: NamedPipe io) protected;
// start listening againbegin

pipe.listenAsynch (self, "listenCallback");
end;

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: NamedPipe Asynch example

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:24 pm

by jadenews.jade.co.nz >> Tue, 16 May 2000 2:08:24 GMT

Thanks Wilfred!

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: NamedPipe Asynch example

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:24 pm

by Robert Barr >> Mon, 22 May 2000 23:34:20 GMT

Here's a few additional tips, gotchas etc you may find useful.

1 watch out for duplicate requests, i.e. the user clicks the same button or link a second time while you are still processing the first request. Results may be undesirable, so I suggest a boolean isProcessing flag to indicate an existing request. A reference to the current pipe can be set on app - this is useful to a global exception handler to determine if a connection is still open.

2 there are a variety of options when extending Wilfred's code to a multiuser and multithreading environment. If you want to pass multiple simultaneous asynchronous requests through a node (e.g. a gateway, or
web server front-ending a legacy host), then you can simply create multiple pipes with the same name, and jadhttp.dll will pass requests to the next available pipe. If processing is essentially synchronous, or
the load is sufficient to require multithreaded processing on the JADE node, then multiple JADE apps can be invoked. For data that needs to be shared between these app instances (such as a session collection), let JADE manage concurrency by creating as sharedTransient.

3 if you are familiar with web scripting environments (CGI etc), you can access the HTTP server data using the getServerVariable() method below. Note that the list of variables shown is incomplete - e.g HTTP_COOKIE
is a useful one.

Cheers,
Rob


getServerVariable(pVariableName : String) : String;
// Sends a request to the jadehhtp.dll to get the server variable value of
// the request field. For more documentation see after 'epilog' of
code.
constants
HEX_NULL : Character = #00.Character;
vars
gsvRequest : String;
bin : String;begin

// Build the request.
gsvRequest := "GSV" & HEX_NULL & pVariableName.toUpper & HEX_NULL;

// Send the request.
writeBinary(gsvRequest.Binary);

// Read the response and return it.
bin := readBinary(0).String;

if bin.length > 1 then
return bin.String;
endif;

return null;

epilog
/* Documentation credited to jadehttp.dll and UIUC
lpszVariableName
A null-terminated string that indicates which variable is requested. The following table lists the possible variables. ALL_HTTP Retrieves all
HTTP
headers that were received. These variables are of the form HTTP_header field name. The headers consist of a null-terminated string with the individual headers separated by line feeds.
ALL_RAW Retrieves all headers in raw form. The header names and values appear as they are sent by the client. Currently, this value is
primarily
used by proxy servers and other similar applications.
APPL_MD_PATH Retrieves the metabase path of the application for the
ISAPI
DLL or the script.
APPL_PHYSICAL_PATH Retrieves the physical path that corresponds with the metabase path. IIS maps the namespace to the physical directory path; this
allows APPL_MD_PATH to return this value. This is a costly function (in run
time) compared to getting just APPL_MD_PATH.
AUTH_PASSWORD Specifies the value entered in the client's authentication dialog. This variable is only available if Basic authentication is used. AUTH_TYPE Specifies the type of authentication used. If the string is empty,
then no authentication is used. Possible values are Kerberos, user, SSL/PCT,
Basic, and integrated Windows authentication.
AUTH_USER Specifies the value entered in the client's authentication dialog
box.
CERT_COOKIE Specifies a unique ID for a client certificate. Returned as
a
string. Can be used as a signature for the whole client certificate. CERT_FLAGS If bit0 is set to 1, a client certificate is present. If bit1 is
set to 1, the certification authority (CA) of the client certificate is invalid (that is, it is not on this server's list of recognized CAs). CERT_ISSUER Specifies the issuer field of the client certificate. For example, the following codes might be O=MS, OU=IAS, CN=user name, C=USA, and
so on.
CERT_KEYSIZE Specifies the number of bits in the Secure Sockets Layer (SSL)
connection key size.
CERT_SECRETKEYSIZE Specifies the number of bits in the server
certificate
private key.
CERT_SERIALNUMBER Specifies the serial-number field of the client certificate.
CERT_SERVER_ISSUER Specifies the issuer field of the server certificate. CERT_SERVER_SUBJECT Specifies the subject field of the server certificate.
CERT_SUBJECT Specifies the subject field of the client certificate. CONTENT_LENGTH Specifies the number of bytes of data that the script or extension can expect to receive from the client. This total does not include
headers.
CONTENT_TYPE Specifies the content type of the information supplied in the
body of a POST request.
LOGON_USER The Windows account that the user is logged into.
HTTPS Returns on if the request came in through secure channel (with SSL encryption), or off if the request is for an unsecure channel. HTTPS_KEYSIZE Specifies the number of bits in the SSL connection key size.
HTTPS_SECRETKEYSIZE Specifies the number of bits in server certificate private key.
HTTPS_SERVER_ISSUER Specifies the issuer field of the server
certificate.
HTTPS_SERVER_SUBJECT Specifies the subject field of the server certificate.
INSTANCE_ID Specifies the ID for the server instance in textual format. If
the instance ID is 1, it appears as a string. This value can be used to retrieve the ID of the Web-server instance, in the metabase, to which
the
request belongs.
INSTANCE_META_PATH Specifies the metabase path for the instance to which the
request belongs.
PATH_INFO Specifies the additional path information, as given by the client.
This consists of the trailing part of the URL after the script or ISAPI DLL
name, but before the query string, if any.
PATH_TRANSLATED Specifies this is the value of PATH_INFO, but with any virtual path expanded into a directory specification.
QUERY_STRING Specifies the information that follows the first question mark
in the URL that referenced this script.
REMOTE_ADDR Specifies the IP address of the client or agent of the
client
(for example gateway, proxy, or firewall) that sent the request. REMOTE_HOST Specifies the host name of the client or agent of the client (for example, gateway, proxy or firewall) that sent the request if reverse
DNS is enabled. Otherwise, this value is set to the IP address specified by
REMOTE_ADDR.
REMOTE_USER Specifies the user name supplied by the client and authenticated
by the server. This comes back as an empty string when the user is anonymous.
REQUEST_METHOD Specifies the HTTP request method verb.
SCRIPT_NAME Specifies the name of the script program being executed. SERVER_NAME Specifies the server's host name, or IP address, as it
should
appear in self-referencing URLs.
SERVER_PORT Specifies the TCP/IP port on which the request was received. SERVER_PORT_SECURE Specifies a string of either 0 or 1. If the request
is
being handled on the secure port, then this will be 1. Otherwise, it
will be
0.
SERVER_PROTOCOL Specifies the name and version of the information retrieval
protocol relating to this request.
SERVER_SOFTWARE Specifies the name and version of the Web server under which
the ISAPI extension DLL program is running.
URL Specifies the base portion of the URL. Parameter values will not be included. The value is determined when IIS parses the URL from the header.



lpvBuffer
Points to the buffer to receive the requested information.

lpdwSizeofBuffer
Points to a DWORD that indicates the size of the buffer pointed to by lpvBuffer. On successful completion, the DWORD contains the size of
bytes
transferred into the buffer, including the null-terminating byte.
Return Values
If the function succeeds, the return value is TRUE. If the function fails,
the return value is FALSE. The Win32® GetLastError function can be used to
determine why the call failed. The following are the possible error values.

Value Meaning
ERROR_INVALID_PARAMETER Bad connection handle, or invalid values, in either
lpszVariableName or lpdwSizeOfBuffer.
ERROR_INVALID_INDEX Bad or unsupported variable identifier. ERROR_INSUFFICIENT_BUFFER Buffer too small. The required buffer size is *lpdwSizeofBuffer.
ERROR_NO_DATA The data requested is not available.


Remarks
The GetServerVariable function copies information into a buffer supplied by
the caller. The information can include CGI variables and information relating to an HTTP connection or to the server itself.

Note In respect to AUTH_TYPE, if the string is not empty it does not mean
the user was authenticated (if the authentication scheme is not Basic or integrated Windows authentication). The server allows authentication schemes
it does not natively support because an ISAPI filter may be able to handle
that particular scheme.

The lpszVariableName can be used to retrieve a specific request (client) header by using the HTTP_headername value. For example, supplying the value
HTTP_ACCEPT returns the Accept header, and HTTP_VERSION returns the Version
header.

The values of the fields for the HTTP_ACCEPT variable are concatenated, and
separated by a comma (,).

If bit 1 of the Cert_Flags variable is set to 1, indicating that the certificate is invalid, IIS version 4.0 and later will reject the certificate. Earlier versions of IIS will not reject the certificate.

For more information on server variables see http://hoohoo.ncsa.uiuc.edu/cgi/env.html.
*/
end;


Return to “Tips and Techniques”

Who is online

Users browsing this forum: No registered users and 11 guests