How to get connection info?

[amrufon]

Hi.

I've got the a simple ICE server and client running over the network. Now, I want to find out who (IP Address) is connected and what he's currently doing or the last operation that he did.

I already tried Ice::Stats and it works great but only gives information on bytes send and recieved. Any ideas?

Thanks.

Alex

[michi]

Originally posted by amrufon
Hi.

I've got the a simple ICE server and client running over the network. Now, I want to find out who (IP Address) is connected and what he's currently doing or the last operation that he did.

There is no API in Ice that would allow you to get at information such as the incoming IP address at the moment. Could you outline what you would like to use this for? If we have a use case, maybe we can engineer somethign that would help...

Cheers,

Michi.

[Lance]

Permissioning clients?

Lance

[amrufon]

Hello.

If you would review my posts, I'm using ICE as a replacement to our existing communication layer build using WINSOCK.

So we basically have a server side application which a lot of clients connect. With our old winsock based code, we were able to determine the number of current connections and what their IP addresses are. So when I replaced our netcode with ICE, we lost the following capabilities:
1. Finding out how many concurrent connections are existing at one time.
2. Identifying the connection source through IP address and being able to identify the actualy computer name.
3. Explicit termination of individual client connections. This is crucial to us since were still in development and we normally terminate connections manually or block a range of address from connecting.
4. Identifying client connection usage.
5. Application auditing.
6. Finding out which client side services are heavily used so that we can optimized it.
7. Just the peace of mind that we know what the clients are actually doing since they have a smorgasborg of server side "functions" that they can use.

A lot of these are can actually be provided by redesigning our current system ... but I am hoping that there are already exisiting facilities in ICE that I could just use so I won't have to redesign all over again. Another thing is that my team is already deep into development and were way passed the design stage. I would be hard pressed to explain why I need to redesign the system just because we changed the communication layer.

Alex

[amrufon]

Can anybody explain more about Ice::current? Can I use this in any way to get more information about the current user(s)?

Thanks.

Alex

[marc]

Ice::Current holds information about the current operation call, i.e., the identity of the Ice object and the operation name. This can be used for implementation techniques, such as a "default servant" for multiple Ice objects. Have a look at the Ice manual (15.7.2 - Default Servants) for more information.

We could add the IP address and port information to Ice::Current. However, it should not be used for security, as IP addresses can be spoofed. A better solution is to use IceSSL for such purposes.

[amrufon]

Hello Marc,

I would appreciate this very much. Although I'd rather change my copy of ICE first until you guys can come up with a better solution.

My basic objective is to identify connections and log their "operations". If this solution is the best one as of this time ... I'll use it until a better one comes up.

Thanks.

Alex

[marc]

If all you need is a log, you can set Ice.Trace.Network=1 and Ice.Trace.Protocol=1

As for connection logging: Note that if you use active connection management, idle connections are closed and re-opened without any explicit user code (to save resources).

[amrufon]

Hello Marc,

I looked-up the Ice.Trace.Network property and I may need to use 3 as its setting. I'm wondering thought where the transaction information are stored? How do I access it?

Although I did say that the basic requirement is to log operations ... I really need more. Because of the nature of my project, I actually have explicit need to kick people off the server and block any connection for a time so that we can do administrative stuff on it.

As I kept saying ... I'll use whatever is availabe (do I sound deperate?) until a better one comes up.

Alex

[marc]

The trace information is not stored. It's for debugging and logging purposes only.

You can hold all requests to the server by calling hold(), followed by waitForHold() on the object adapter. Later, when your administrative work is done, you can call activate() on the object adapter again, so that it continues processing requests.

In case the administration work is done remotely via Ice calls, you can use two object adapters: One for administrative operations, and another one for the regular user requests. In this case, you only set the non-administrative object adapter on hold, but leave the administrative one active, so that administrative requests are continued to be processed.

[amrufon]

Hello Marc,

Thanks for the info on how to do remote administration. I'm still at a bind on how to manually manage connections though.

Consider the attached image. This is actually a screen capture of our original conneciton monitoring/management modules that was using winsock.

We initially used it to monitor usage through hierarchical tree where the highest nodes are connection information and the branches are object opened and operations being processed.

Any thoughts?

Alex

[marc]

I'm afraid there is no way to manage connections manually in the current version in Ice. It's all automatic. And as I wrote before, managing connections manually is problematic, because there might be no 1:1 relationship between clients and connections. (Doing so would hurt scalability and fault-tolerance.)

The way to do what I think you want to do is to manage "sessions" rather than connections. Glacier, our firewall solution, supports session management: When a new user logs in, a session is created, and when a user logs out or the connection drops (timeout), the session is destroyed. You application can then track these session objects, display information about who is "logged in", etc. And all this is done in a secure manner.

[amrufon]

Hello Marc,

Thanks for the info about Glacier. It just means I have more research to do.

I'm currently considering doing the following just to get the connection information though.

interface jSockets
{
string jclCommand(string command,string connectioninfo);
};

This looks cludgey and I'll have to get the connection info in the client side and send it to the server just for monitoring. I had hoped that theres a better way.

Thanks again.

Alex

[sylvain]

Hi Alex,

Maybe you can use Ice::Context instead of explicitely adding a new parameter to your Ice operations.

You can create an Ice::Context object somewhere at the begining of your client program that will store relevant info such as a stringified IP address in the way you want.

Then you just add this Context object as the last parameter of every call through proxies (as it is described in the Ice documentation 16.8). The servant will then receive the Context object via the Current object. You can then do whatever you want, including just returning if the IP is to be blocked (and you also get the operation name with the Current obj).

Of course this is not secure and create a little overhead, but maybe it could be a first easy solution, and you don't need to modify your existing slice files.

I don't know if there is a way to declare a default Context object that could be use as implicit default parameters when invocating from client (if yes then you don't even need to change to much your client code).

I don't know if the Ice creators will agree with this post, but maybe it could help you.

Sylvain

[marc]

Originally posted by sylvain

I don't know if there is a way to declare a default Context object that could be use as implicit default parameters when invocating from client (if yes then you don't even need to change to much your client code).

Currently you can't set a default context, but it's on our TODO list.