Products

Price/Order

Support

Partners

Testimonials

Test Results

About us

Contact
 How to gather information on connected clients.
Bottom
 
Total posts: 13
 Author How to gather information on connected clients.
Gary Bell

21.09.2006 14:01:25
Registered user
Well, it's me again with a goofy question.  I'm writing a server that handles synchronization of data tables between clients and a main database.   Essentially, clients connect, login and send a series of commands, data streams, etc.   This usually happens pretty quickly, but sometimes this process can take 5-15 minutes.   I would like to have a "management" interface to this server where I could remotely request to see who is online, what they're doing, when they logged on, etc.  I may also want to instruct all the clients to disconnect (maybe by force).  Things like that.

I see it's pretty easy to get the number of connected clients, but is there a way to enumerate all the connected client connections so I could say do a PostJob or query there session info?  Or, should I populate some global structure (thread safe of course) with the information in the OnClientConnect.  Update it as needed and then remove the information from the global structure in the OnClientDisconnect?

Thanks,

Gary
Danijel Tkalcec [RTC]

21.09.2006 16:34:03
Registered user
Since the only place you should be allowed to access connections on the Server is from the events triggered by the components, I didn't want to encourage someone to enumerate through available connections and try sending something out, which will (in most cases) just screw that clients connection up.

If you just want to collect information and be able to check what which client is doing, you can use the events (OnConnect, OnDisconnect, etc) and manage your data somewhere, but keep in mind that Server is NOT ALLOWED to do anything else but disconnect ALL the clients by calling StopListen and react to events triggered by the connections. Do not try to post messages to the connections maintained by the Server, nor read/write/access sessions created by those connections.

I have to say, after reading through your post, I've started to picture all sorts of horror scenarios where you will write something that will result in a very unstable Server. I'd really like you to get your statistics and be able to communicate with the Server, but please avoid keeping TRtcConnection components in lists and using them for anything. As said, those components should only be used from within events. If you want to be able to send messages to clients, you should implement your own "message pool" and your clients should be calling functions on the Server to pick their messages up.

I repeat: you can do what ever you want with a connection inside events triggered by the connections on the Server-side, but do NOT access those objects from outside those events. You can collect all the information you want/need from inside those events (when a client requests something from the Server).

Best Regards,
Danijel Tkalcec
Jerry Hayes

21.09.2006 16:44:13
Registered user
Danijel,

There's no problem have a function call walk sessions and report stats on these, right? (as long as it doesn't send anything to clients)
Gary Bell

21.09.2006 17:19:56
Registered user
Danijel,

That's what I needed to know.  I'll continue with the plan to manage my data in some global structure. It will only be access via events. That's all I know how to do now anyway, but once I know more about what I'm doing is the following statment from the help file applicable or am I misunderstanding what you said about accessing the connections from outside the events?

"To be able to access the connection components from anywhere else than your event handlers (for example, from a Button click event), even when they are running in multithreaded mode, you will use TRtcConnection components ability to POST A JOB to itself."

I certainly don't know enough to do this yet, but I had this vague idea of being able to enumerate the list of active connections and "Post a Job" to it.  

Thanks,

Gary
Danijel Tkalcec [RTC]

21.09.2006 18:50:16
Registered user
1) to Jerry ...

you will not get access to a Session, unless the "FindSession" or "HaveSession" methods are being called from the connection object which has created the session, since sessions are locked to IP addresses and will not be visible to any other client than the one which has created it. So, to answer your question, you can NOT walk sessions and report their status, since each connection only has access to Sessions created by "itself" (better said - created from clients coming from the same IP address).

I could change the implementation here to make sessions visible to all IP addresses, but I see this as a security risk, since hackers could use sniffers and grab already open sessions to gain access to data which should only be visible to the user which has opened the session.

2) to Gary ...

I guess, I should watch more closely what I write in my help files. This statement is true, but you can only post jobs to existing objects. Since all connections accepted by the rtcHttpServer component are maintained by that component, you have to be very careful if you are storing pointers to those objects somewhere and using those pointers to do something with those objects. You could end up with "random" Access Violations (for example, when you try to post a job, but the object is no longer valid because it was destroyed by rtcHttpServer).

Btw ... in 99,9% of all applications written with RTC SDK, you will never need to post jobs to a connection object. All Server-side code should be written inside events, where you have unrestricted access to the connection component, and ... client-side components are designed to work from the main thread in multithreaded environment, or (when HyperThreading=True) from any number of threads.

I hope you won't decide to go too low-level with your implementation. You should be able to do everything you want on the Server, simply by implementing events made available by the components.

Best Regards,
Danijel Tkalcec
Gary Bell

21.09.2006 19:24:47
Registered user
You've convinced me.  I'm sure there's nothing I need to do that I couldn't accomplish elegantly from events.  Most of my questions come from confusion transitioning from the Indy/Blocking world to the RTC/non blocking way of doing things.  You probably can't tell from my questions, but I'm slowly starting to get it.  

Thanks for all you help,
Gary
Jerry Hayes

21.09.2006 19:46:09
Registered user
1) to Jerry ...

I could change the implementation here to make sessions visible to all IP addresses, but I see this as a security risk, since hackers could use sniffers and grab already open sessions to gain access to data which should only be visible to the user which has opened the session.
------------------------
Danijel,

Would be nice, but not a huge deal; I can always create a global thread-safe list on my own and update it on SessionOpen, SessionClose, etc.
Sebastian Zierer

21.09.2006 22:45:09
Registered user
to Danijel...

You wrote that you lock the sessions to IP addresses. How is that going to work? Some ISPs use (transparent) proxies so every user appears to have the same IP address. To make things even more complicated, there might be two or more proxies so that you cannot even be sure that a users keeps his IP address. The 2nd request might come from another proxy even though it is the same user.
Danijel Tkalcec [RTC]

21.09.2006 23:19:54
Registered user
Sebastian,

I know that multiple clients could come from the same IP when going over a Proxy and that the same client could come from multiple IPs, when a proxy gateway is in place. But, using an internet proxy Server is also a huge security risk. If I was doing something where security of my data is important, I would *NEVER* use someone else's Proxy Server (or some anonymous Internet Proxy). So, if you are ready to send your data through a proxy server, there's nothing I can do for securing your data. But, those who know about security risks of using a proxy will avoid them where possible. And that's where the Session-to-IP lock is one additional safety check.

PS. I cam add a global parameter to the RTC SDK, which would disable the Sessions-to-IP lock, but I will leave this enabled by default.

Best Regards,
Danijel Tkalcec
Sebastian Zierer

22.09.2006 06:38:41
Registered user
Well, many large ISPs have a transparent proxy. That means they will route all http traffic over this, without that a user actually knows about this. AOL is probably the most well known example as far as I know. So it's not really the user's choice, unless they change their ISP.
Danijel Tkalcec [RTC]

22.09.2006 12:44:49
Registered user
Exactly. Unless they change their ISP, which is also *a choice* (nobody is forcing you to choose AOL).

So, if you don't want your data to be shuffled over a proxy (I for sure don't), you will choose an ISP which doesn't do that. And with the built-in Session-to-IP lock in the RTC SDK, you can rest assured that outsiders won't be able to "tap into your sessions".

Naturaly, as I said, I can make this "lock" optional, so it will be your choice whether you want to use this additional security option - or don't. The most important thing is that you have a choice.

Best Regards,
Danijel Tkalcec
Sebastian Zierer

22.09.2006 16:59:17
Registered user
I can choose my own ISP, but I cannot tell my clients to not pick a particular ISP, because their sessions will either be unsafe or don't work at all. From a customer's point of view it means that my server (or forum) has a problem.

If you make the "lock" optional, then no visitors would have the problem with loosing a session.

But then there must be some other thing to prevent the loss of sessions, no matter if you make that lock optional or not. Let's assume you have a forum where an attacker could post a link to his website. Then he will get the session ID of any user that clicks on the link. Now if both are behind the same proxy, then the attacker could easily grab the session ID and use it. If this scenario was in the rtc forum then the attacker could download the rtc source without paying for it. Now who is the one having the problem?
So never store the session ID in the url, unless you absolutely have to. Use session cookies instead.
Danijel Tkalcec [RTC]

22.09.2006 17:20:58
Registered user
First, I'd like to point out that RTC SDK is used by a number of companies and developers, each having different requirements, especially in the field of communication and data security. Even though locking a Session ID to an IP address doesn't shield you from all possible attacks, it does add to clients security and that's the only point that matters to me.

As for your tip about using cookies ...

1) Hackers don't use Browsers to hack into a WebServer, they have HTTP clients which they can use to send whatever they want (including their own fabricated cookie). You can easily use the RTC SDK to write your own HTTP Client, which enables you to send anything you like in HTTP headers.

2) A lot of Browsers have cookies disabled, so any web application depending on cookies will not work there. That's the only reason I've decided to send the Session ID in the URL and not inside a cookie.

Best Regards,
Danijel Tkalcec