Multi-Process RPC Listener Host System for RC5

Alright glad you got it running :)

Hope you like what you see once you get a chance to really try it out. Feel free to come back here any time for assistance if you need it. :wave:

I've updated both Rc5RpcHost in post #1 and the chat client demo in post #16 to support encryption. It will be auto-configured and enabled if an encryption key pair is found on the server.

If you are only trying the client app demo, then just run/recompile the latest source code and it should automatically configure itself to use encryption against the demo server at chatdemo.statslog.com.

If you are trying out hosting your own server, you will need to recompile Rc5RpcHost.exe as it now includes the necessary encryption key pair generation code. In most cases the server should automatically generate it's own keypair now, UNLESS you are running Rc5RpcHost.exe in a Windows protected folder location. In that case you should generate the key pair manually (one time) in an elevated command prompt with the following command line:

Code:

---

rc5rpchost.exe /genkeys

---

Enjoy :)

very good work continues, two things.
1) it works perfectly when I do everything in local mode, but when I try to connect to your server fails.
RPC-ClientError: Wrong Length of File "RPCPublicKey.DH"; or file doesn`t exist!
only fails to connect to your server's, not local.
recompile the client and Rc5RpcHost.

2) My Avast antivirus detected it as a virus.

greetings and good job

Hi yokesee - thanks again for testing things out and reporting back here. I will take a closer look first thing in the morning.

Hi yokesee,

I've figured out what's going wrong. Even though I'm using an in-memory only public key for encryption, it seems that RC5 requires a copy on disk (even though it will be replaced by the in-mem key). The reason things work OK when testing locally is because your test client & server \libs\ folder has the required RPCPublicKey.dh file. I've sent a message to Olaf to see if this can behaviour can be changed so we'll see.

In the meantime there is a workaround. I've had to change the order of setting the .Encryption and .Password properties in the client, so you will need to download the latest version from post #16. You should also copy the included RPCPublicKey.dh file to the App.Path\libs folder after compiling. Once that is done you should be able to connect to my cloud demo server.

Thanks again for reporting the issue!

Quote:

---

Originally Posted by jpbro

I'm not going to pretend to be any where close to knowledgeable enough on chat software or massive scale app developement, so I can't really give you a good answer on this. I've also never used WhatsApp, so I'm not sure what kind of features it has (if it has Video streaming and stuff, then I don't even want to think of what would be required programming-wise).

But let's assume it's just a text based chat program you are writing - with niceties like emojis, links, etc... but basically just text data going back and forth. We're just pumping bytes around, so I think it could be done in theory. That said you'd have to design a heck of a system in terms of things like:

- How do you keep track of who's online?

- How many back-end servers do you need? Where should they be geo-located?

- How do you route a message that arrives on one server to a user that is connected to another server?

- Do you hold messages that are sent to users that are offline? How much space will you need to store all of these?

- At 10million+ users, even logging connections, messages, errors, etc... sounds daunting (to say the least).

- Should there be PUSH notifications to users? I'm not sure that this is possible with RC5 (though Olaf could chime in if he has time), but right now I'm using a polling method that I don't think would scale too well. As mentioned, the chat app was just a simple app example to show how to communicate with a server and store/return data - it's not supposed to be an example of a "good" chat application, just a proof of concept.

That's just stuff off the top of my head.

I guess you could try stress-testing a private server by writing an app that will open a lot of connections and send messages to the server to see when it starts become unusable. Whatever # you get, divide it by 10 million and then see how many servers you would need.

All that said, take the above with a grain of salt as I have no experience with apps anywhere near that scale.

---

Hi jpbro, thank you for your detailed reply. When I have time, I'll learn more about how to process massive data.

Just a little update that shows the stability of the system. It's been running untouched by me for almost 2 weeks now and uptime is 100% :)

Attachment 173785

what is the response time measuring?

The graph/uptime monitoring is from a third-party service I use and TBH I don't really know what their response time is measuring. I probably should have not included it in the image above since it doesn't seem to match my real world test I've done. Maybe it's the total time for the monitoring service to get a response, parse it, and log it?

For example, my ping time to the server is <15ms, and my total time to receive the HTML status page over HTTP is usually in the 30-50ms range:

Attachment 173797

The server is pretty close to me geographically though, so maybe that's why I'm seeing much better times. Be curious to see what others are getting for Ping and total HTTP response time for http://chatdemo.statslog.com.

Quote:

---

Originally Posted by jpbro

The server is pretty close to me geographically though, so maybe that's why I'm seeing much better times. Be curious to see what others are getting for Ping and total HTTP response time for http://chatdemo.statslog.com.

---

http get - 115ms (57 connect, 58 wait)

ping - 60ms

Thank you for reporting the results of your test!

I think a lot comes down to your distance from the server (which is in Toronto, Canada). I only start getting >50ms ping times to sites outside of North America, so if you're in North America that does seem a bit slow (but I guess there could be a lot of hops between us). The 55ms or so leftover for HTTP traffic is close enough to what I get (typically 30-50ms), so I don't see anything unusual there. Remember though that I'm running the server on a dirt cheap $5/month VPS with a single v-core, so I don't expect the performance to be mind blowing.

The other thing to note is that the HTTP/HTML page performance isn't really relevant, since that data is simply used to quickly test whether the server is still listening/responding to requests.

I think a better test would be an RC5 RPC traffic test, since that's the transport we'll be using for our actual software (in this case the chat demo). I've added a CTest class to the ChatServer.dll that includes a very simply public method called "TestLongByRef". If you pass a Long to server via RC5 RPC it will add 1 to it and copy the result back into the passed long on the client side. It's a very simple method that attempts to mostly measure the time of the network transport as opposed to any heavy work the server might need to do.

I then used the following code to profile this:

Code:

---

Sub TestLongByRefLoop()
  Const c_LoopSeconds As Long = 3
 
  Dim l_Long As Long
  Dim cc As vbRichClient5.cRPCConnection
  Dim dd As Double
  Dim ii As Long
     
  l_Long = 5000
 
  Debug.Print "ByRef Value before loop: " & l_Long
 
  dd = New_c.HPTimer
 
  Set cc = New_c.RPCConnection("chatdemo.statslog.com", 80, True)
 
  Debug.Print "Connect time: " & Format$((New_c.HPTimer - dd) * 1000, "#,##0.0") & " ms."
 
  dd = New_c.HPTimer
 
  Do
      ' Call the same RPC method over and over for c_LoopSeconds seconds.

      cc.RPC "ChatServer.dll", "CTest", "TestLongByRef", 10, l_Long
     
      ii = ii + 1
  Loop While New_c.HPTimer - dd < c_LoopSeconds
 
  Debug.Print "RPC Calls/second: " & (ii / c_LoopSeconds)
  Debug.Print "RPC average time: " & Format$(c_LoopSeconds * 1000 / ii, "#,##0") & " ms."
  Debug.Print "ByRef Value after loop: " & l_Long
End Sub

---

With the KeepAlive option on the RC5 RPC Connection object set to TRUE*, I get the following results:

Code:

---

ByRef Value before loop: 5000
Connect time: 2.3 ms.
RPC Calls/second: 70
RPC average time: 14 ms.
ByRef Value after loop: 5210

---

So ~70 RPC calls/second (or ~14ms per call). The time it takes seems network bound since the CPU load during this time is minimal even after slamming the server by running the code for 60s in a loop:

Attachment 173809

* With KeepAlive=False, RPC calls/s drop approximately 60% due to disconnect/reconnect overhead.

Thought I'd post back here one more time before I shut down the demo server, likely in the next few days.

Here's the latest uptime report:

Attachment 174331

As you can see 100% uptime after a month of service with no interventions required after initial setup.

Just wanted to show that you can create and host a high availability VB6 app server in VB6 using RC5 +Rc5RpcHost.exe, all for a measly $5/month on a VPS.

I haven't had time to test it (I'm busy with other things). But I already have experience using VBFCGI, I believe Rc5RpcHost will definitely bring great help to my work. Much appreciated, jpbro.

FYI - THE DEMO SERVER HAS BEEN DECOMMISSIONED AS OF FEB 18, 2020

Just a heads up to any future visitors - I've taken down the demo server since it has served it's purpose as a proof of concept. Thanks to everyone who tried it out :)

you done a great job.
I have it pending.
when the time to leave me.

Greetings