The noncallback server and Broker Development Kit patches discussed by Joel
Ivey in an email I partially excerpted back on December 21 are now in
fpt.va.gov/vista/Software/Packages/RPC Broker - XWB directory dated 2/9/2005.
These should solve the problem of getting through firewalls, at least with
the newer versions of VistA and CPRS. I still have one of the older versions
I am working with. Perhaps someone could test it with the new versions of
Cache.dat and the GTM version dated 2/12/05 if you have them up and running.
(Thurmon, have you got it going yet?)
I have patched together parts of email sent to me by Joel to give you an
overview to what theses do. There is also a nice discussion in the text file
that accompanies the patches.
*************************
The connection made by the new version broker and server side is a
non-callback connection, thus much like Telnet so that if it can get through
the firewall on a specified port, then it does not need the call back to a
separate port that was used previously (and this is the reason that they
have problems going through a firewall that doesn't have all ports open).
All of our source code has been available via FOIA, and the new versions
will be no different.
The Broker Development Kit (client side code for Delphi) includes souce code
which has been compiled (and the compiled units are included as well) with
Delphi 5, 6, and 7.
The server patch (XWB*1.1*35) and BDK patch (XWB*1.1*40) are in the final
stages before official release, and probably should be available shortly
after the beginning of the year.
*********************
In reference to Kevin's solution:
Something close to that was one of the options that we considered. However,
that will limit a user to a single application connection to that port
number. If this is not a problem, it will work fine. However, we had to
consider the possibility (probability) that a user might want multiple
applications open on the same port number. Our solution provides that
capability.
**********************************
The solution that we chose was to use a UCX-type listener on the server (on
VAX and I believe GT.M) that does not require a callback and is similar to
the type of connection made with telnet. This and the use of different
initial headers ( {XWB} vs [XWB] (new style) vs <XWB> (M2M broker) ) also
provides the ability to differentiate between the old style connection and
the new style so that some new parameter types could be added for data
transfer (e.g., a global list in addition to a list). On NT, I believe the
connection as it is made spawns off a new listener, so that it does not have
to do a callback as well.
Nancy Anthracite
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
