Re: RTC remoting > Explained in 11 minutes

Sharing a connection between 2 incompatible component sets, which probably
don't even know they are using the same connection, could very easily result
in unforseable problems. For example, both components could try to send
something out at the same time, or they could be "fighting" for the data as
it comes in.

I guess I need to explain myself a bit better. NexusDB uses special
transport components for connections between clients and servers. There
is an abstract base class and 3 implementations currently, TCP/IP,
NamedPipe and SharedMem. These transport components can handle any
number of threads making calls against them at the same time and they
allow full 2 way communication (meaning not only client request ->
server response but also server request (to client) -> client response)
with only client initiated physical connections (preventing problems
with clients that may be behind firewalls or NATs and cannot accept
incoming connections.) Normally you would have the following component
chains:

Client: TnxRemoteServerEngine -property-> Tnx???Transport --|process
boundary|--> Server: Tnx???Transport -property-> TnxServerCommandHandler
-property-> TnxServerEngine

TnxServerEngine and TnxRemoteServerEngine both derive from an abstract
base class and contain largely the same set of methods (inherited from
that base class). Calls against the TnxRemoteServerEngine create
messages containing all the in parameters of the calls which are then
handed off to the transport (with a specific message ID). When the
message arrives on the server it ends up with the command handler which
decodes it based on the message ID and makes a call to the attached
TnxServerEngine that's identical to the call that happened against the
TnxRemoteServerEngine in the client. When that call returns all out
params and the result are packed into a message again and returned to
the client where the TnxRemoteServerEngine was waiting for this reply.
Once it arrives the reply is decoded and the out params and reply value
set accordingly before the call returns to whoever called the method on
TnxRemoteServerEngine. All that is working fine with any number of
threads making calls at the same time.

Now, it's possible to hook into this communication system in a
controlled way. There is a TnxBasePluginCommandHandler class that you
can derive from and any number of which can be hooked up to the
TnxServerCommandHandler. If a message arrives that is not handled by the
server command handler (because it has an unknown message ID) then it's
handed off to the different attached plugin command handlers which have
a chance to react to that message. Naturally there is a way on the
client side to send custom messages (which will block until a reply is
available and then return with the reply).

There will be absolutely no problem with components "fighting" over data
as it comes in or clashing when sending out data. The transports are
designed to support any number of threads operating on them
simultaneously and to route the messages correctly to their intended
recipient.

Now, the "normal way" you would go ahead and use this is to create your
own abstract base class defining the methods your plugin will support
and deriving 2 classes from that, one that does the actual work and one
that creates the messages and hands them off to the transport. You'll
also have to write a plugin command handler which reacts to the message
IDs you use (one per method) and turns these messages into method calls
against your attached "real" plugin. That works very well and results in
extremely fast remote calls. But it does require a certain amount of
work to manually write the proxy ("remote engine") and stub ("plugin
command handler") code.

What I would like to do is to write a special "remote plugin engine"
"plugin command handler" and "real plugin engine" once which only uses a
single message ID "encapsulated RTC". On the client side instead of your
components opening socket connections and sending the data themselves I
would like them to just call a method on that remote plugin engine,
passing in 2 streams. One containing a request and another one which
will have the reply written into before the call returns. On the server
side there should be a method on your server component that can be
called passing in 2 streams, one containing the request and the other
getting the reply written into before the call returns. That would make
it possible to transparently tunnel an RTC connection over the existing
transport.

It's a concept that has already been shown to work well with other RPC
toolkits available for Delphi (RemObjects and kbmMW).

In the component chain I explained above it's also possible to attach a
command handler (and plugin command handlers to that) to the transport
on the client side. In that case it becomes possible to send messages
from the server to individual (or broadcast to all) clients that arrive
at the client and can be processed in exactly the same way that messages
arrive at the server. This works with physical connections only
established from client to server, never from server to client. So there
are no problems with firewalls or NATs on the client side. This allows
hassle free callbacks from server to client.

Regards,
Thorsten Engler
.

Relevant Pages

  • Re: Network intermittently dropping the connection to shared files on server
    ... what we were using with our SBS2000 server with no problems. ... It's a small Server plus 4 Client W/S set up in one office. ... All users that have current connections to the shared files are ... We have a small network < 5 clients connected to a new Dell ...
    (microsoft.public.windows.server.sbs)
  • Re: TCP server stop receiving new connections
    ... reset the event mask of your listening socket each time you ... I have a strange problem in my class library used by all our client ... server applications. ... incomming connections, but keeps current connections. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Network intermittently dropping the connection to shared files on server
    ... ISA Server detected routes through adapter Loopback that do not correlate ... It's a small Server plus 4 Client W/S set up in one office. ... All users that have current connections to the shared files are ... We have a small network < 5 clients connected to a new Dell ...
    (microsoft.public.windows.server.sbs)
  • Re: CSocket question
    ... client for some reason disconnects. ... server checks for idle time there can easily be 5-30 connections that are ... connections were actively sending data. ...
    (microsoft.public.win32.programmer.networks)
  • Re: More Than One VPN from Home?
    ... What about an application server at the office that the remote users ... situation I need to use it, the broadband connections at the servers location ... bit of client traffic using the DSL bandwidth at the SBS location, ...
    (microsoft.public.windows.server.sbs)