dhRichClient3 RPC to private class in same project/exe as listener
JPB
function in a private class that is in the same project/exe as the RPC
listener object? Something like:
mo_RpcConnection.RPC "", "Class1", "Test", 5
Where the first parameter (empty string in this sample, which is
normally a DLL filename) would mean that the listener would try to
create the class from its own project...I've tried the empty string
(didn't work), but I was wasn't sure if there might be a magic string
that would do the trick (the way we have the ":memory:" string for in-
memory SQLite DB connections).
Thanks in advance for any help!
Schmidt
"JPB" <jasonpe...@gmail.com> schrieb im Newsbeitrag
news:0c11dfeb-ae5a-4f70...@j24g2000yqa.googlegroups.com...
> I suspect not, but I was wondering if there is any way to call a sub/
> function in a private class that is in the same project/exe as the RPC
> listener object? Something like:
>
> mo_RpcConnection.RPC "", "Class1", "Test", 5
No, the RPCListener-Host-Exe (after instantiating
and firing up the listener-thread-class) is running
somewhat "isolated" from these threads.
RPCListenerHost.exe (Main-Thread)
RPCListenerClass (on its own thread)
RPCWorkerPoolThreadClass
RPCWorkerPoolThreadClass
RPCWorkerPoolThreadClass
....all workers on their own threads
The best way would be, to isolate the currently
private Class "Class1" and its functionality into
a separate ActiveX-Dll - this way the (then public
reachable) functionality of Class1 would be available
directly inside the RPCListenerHost.exe (regfree
instantiated per DirectCOM for example) - but also
reachable over a RPCConnection-Object, running
within the ListenerHost-exe per:
mo_RpcConnection.RPC "MyNewHost.dll", "Class1", "Test", 5
over sockets.
Don't know, what you want to achieve finally - maybe
shade some more light on this - if it's more for debugging-
purposes, then look into the DB-Group, where I've
already posted the needed steps to setup roundtrip-
debugging - or if it is more thought for something like a
"serverside singleton-class" - but for that is also something
"built-in".
Olaf
JPB
Thanks a lot for the reply.
The main reason I wanted to keep the classes private was I didn't want
anyone calling the methods outside of my software (by creating their
own instances of the classes, which is possible if they are available
in an ActiveX DLL).
I guess what I will do instead is encrypt the data between the client
and server. For example, instead of having a something like:
Public Property Let MaximumClientsAllowed(ByVal p_Max As Long)
' Save the maximum # of clients allowed to use the program here
End Property
Public Property Get MaximumClientsAllowed() As Long
' Retrieve maximum # of clients allowed to use the program and
return that number
End Property
I will do something like this:
Public Property Let MaximumClientsAllowed(ByVal p_EncryptedValue As
String)
' Decrypt p_EncryptedValue, validate it and save the maximum # of
clients allowed to use the program here
End Property
Public Property Get MaximumClientsAllowed() As String
' Retrieve maximum # of clients allowed to use the program, encrypt
the value and return the encrypted string
' Client will have to decrypt the return value to determine the
Maximum # of clients allowed
End Property
This won't stop a determined hacker (not going to waste my time trying
to do that), but it will prevent curious tinkerers from modifying
sensitive data.
Unless anyone has a better idea?
Thanks again,
Jason.
Nitin
"JPB" wrote:
Well my guess Is u r trying to restrict no of users which can connect to
the server based on licenses user/company obtains from developer
<for olaf >
if there would have been new connection event / client connection event
in rpclistener then code to restrict users can be written there
apart from rpc connection I ask my clients to may be login/register themselves
additionally & then put code to restrict connections there
Schmidt
> The main reason I wanted to keep the classes
> private was I didn't want anyone calling the methods
> outside of my software (by creating their own instances
> of the classes, which is possible if they are available
> in an ActiveX DLL).
Ah Ok ... but passing encrypted setting-values
is a nice "workaround" in that case, as you already
suggested yourself.
>
> This won't stop a determined hacker (not going to waste
> my time trying to do that), but it will prevent curious
> tinkerers from modifying sensitive data.
>
> Unless anyone has a better idea?
As Nitin already wrote, you could also establish a
session-scheme over a dedicated Login-Method,
which passes back a Session-, and/or UserID into your
(RPC)ClientApps - and this SessionID would then
be valid for a fixed timeout of, let's say 1 minute -
and you could ensure in your ClientApp, that this
SessionID-TimeOut would refresh itself (in a small
TimerProc for example) for another minute, if this
timer does its SessionID-Refresh (updating the "expires-at"
value e.g. in a DB-Table) each 30seconds or so.
This SessionID could also be used in each RPC-call
(as an additional param), and if the passed (randomly
created ID) is not in the list of "currently active sessions",
then the serverside would instantly jump out of the
RPC-routine in question, doing nothing.
Easy to integrate a "Max-Sessions-allowed" check
into something like that.
You could store the current session-list in a small
dedicated SQLite-DB (maybe an encrypted one)
with only one small "Session-Table", so that the
information stored there is made persistent on disk,
and then reachable from each of the workerthreads
in a normal Rs-Open-Call.
This would add about 0.2 - 0.4 msec overhead to
each of the RPC-Calls, not all that "costly" IMO,
in case your usercounts are below 100 or so -
and the RPC-frequency of the incoming calls is
not higher than maybe 10 per second in the worst-
case.
Olaf
Schmidt
"Nitin" <Ni...@discussions.microsoft.com> schrieb im Newsbeitrag
news:94619AF7-1868-4628...@microsoft.com...
> <for olaf >
> if there would have been new connection event / client
> connection event in rpclistener then code to restrict
> users can be written there
That would be possible, if the RPC-scheme would only
allow connections, based on a ("durable") TCP-Connection.
But this mode is switchable at the clientside RPCConnection-
Object also to "reconnect in each RPC-request" over:
ClientRPCConn.KeepAlive = False
Aside from (or because of) that I've always hesitated, to
introduce something like "serverside Events" into the whole
RPC-scheme of my toolset, since such "Events" (if done
over sometimes not that reliable socket-connections as e.g.
Internet-(DSL)Dialups or WLAN-connections) are always
error-prone.
Better to hold the state of "something" at the serverside
in a DB, a File or a Singleton-Class - and cyclically check
with well-choosen polling-intervals, from all connected
clients periodically in a separate roundtrip (which could
be used, to also update clientspecific, new values in the
same RPC).
That's the most reliable way, even if the socketconnections
are not that stable as in a "wired LAN" - the Appclication
works much more robust this way, even if a ClientProcess
is hard-terminated, or if a wire (e.g. on a Notebook) is
plugged off (since in these cases you would be doomed,
if you would rely on "Server-Events" - these wouldn't
be triggered in such cases).
> apart from rpc connection I ask my clients to may be login/register
> themselves additionally & then put code to restrict connections
> there
Yep - a simple Login-Routine (either GUI-based, or just
a simple "hidden one", if you don't need special UserName/
Password-Input) which will either deliver a Session- or
UserID, or just an "access-denied" - or "MaxConnections
exceeded" response would be sufficient.
Olaf
JPB
The advice to go with a login/session ID method made a lot of sense.
I've implemented this using a server-side singleton class that stores
session IDs in a collection, and it is working great. Initially I had
some trouble because I was trying to get the singleton working using
the old dhRichClient2 method, but that will teach me for not looking
at more up-to-date sample code!
For the session ID, I'm using dhRichClient methods from the cCrypt
class as follows:
l_SessionId = lo_Crypt.GetHashedPassword(lo_Crypt.CreateRandomNumber)
I suppose that getting the hash of the random number isn't required,
but I do like all the session IDs to be the same length for aesthetic
if not practical reasons.
Again, thanks a lot for your input.