Shivakumar, please refer to:
http://rpyc.sourceforge.net/api/utils_authenticators.html#api-authenticators
and
http://rpyc.sourceforge.net/api/core_protocol.html#rpyc.core.protocol.DEFAULT_CONFIG
first, you can use a mock authenticator, such as this:
def get_peer_name(sock):
return sock, sock.getpeername()
next pass it to the server, so that you could access the peer name as
conn.config["credentials"]
another approach is to dig into the connection itself. it has a _channel
attribute that has a _stream attribute.
the stream, in this case, would be a SocketStream, and it has a _sock
attribute, which is the actual socket object.
you can use getpeername() on it.
but the first method is more elegant.
-----------------------------------------------------------------
*Tomer Filiba*
tomerfiliba.com <http://www.facebook.com/tomerfiliba>
<http://il.linkedin.com/in/tomerfiliba>
On Mon, Feb 27, 2012 at 07:53, Shivakumar GN <[email protected]>wrote:
> Hi Ruediger,
>
> Socket is not available in the sub-class of rpyc.Service isn't it?
>
> Seems like it is available as a member of rpyc.Server in the form of
> self.listener, but the information is needed in Service class so that
> the exposed services can use this piece of information.
>
> Am I missing something here?
>
> thanks & best regards
> Shivakumar
>
>
> On Sun, Feb 26, 2012 at 10:36 PM, Rüdiger Kessel
> <[email protected]> wrote:
> > Hi,
> >
> > you can get the ip-address of the client from the socket using
> > getpeername() if you need to identify the client.
> >
> > Greetings
> > Ruediger
> >
> > 2012/2/26 Shivakumar GN <[email protected]>:
> >> Thanks.
> >>
> >> I was looking for means to identify client by IP or hostname so that
> >> some smarter functionality is possible on server.
> >> But the below solution is just about ok for me.
> >>
> >>
> >> On Thu, Feb 23, 2012 at 7:18 AM, Rüdiger Kessel
> >> <[email protected]> wrote:
> >>> Hi Shivakumar,
> >>>
> >>> if you use a threading server something like this will work:
> >>>
> >>> class MyService(rpyc.Service):
> >>> _ClientID=0
> >>> activeConnections=0
> >>> LOCK=Thread.allocate_lock()
> >>> def IncClientID(self):
> >>> MyService.LOCK.acquire()
> >>> MyService._ClientID+=1
> >>> self._ClientID=MyService._ClientID
> >>> MyService.LOCK.release()
> >>> def on_connect(self):
> >>> self.IncClientID()
> >>> MyService.LOCK.acquire()
> >>> MyService.activeConnections+=1
> >>> self.writeaccess=MyService.activeConnections==1
> >>> MyService.LOCK.release()
> >>> def on_disconnect(self):
> >>> MyService.LOCK.acquire()
> >>> MyService.activeConnections-=1
> >>> MyService.LOCK.release()
> >>>
> >>> If the client who has write access quits then none of the other get
> >>> write access. So this is not bullet prove but might work in your case.
> >>>
> >>> Rüdiger
> >>>
> >>>
> >>> 2012/2/23 Shivakumar GN <[email protected]>:
> >>>> Hi All,
> >>>>
> >>>> I am creating a rpyc server that provides services of "read" and
> "write" nature.
> >>>> My need is - if multiple clients are connected, "write" must be
> >>>> possible by only one client while all other clients can have "read"
> >>>> access.
> >>>>
> >>>> Any suggestions on how to address this in a clean way?
> >>>>
> >>>> Seems like this requires:
> >>>> - when a new client connects, being able to store client
> >>>> information in a manner accessible to sub-class of rpyc.Service
> >>>> - providing a mechanism to request write access
> >>>> - noting which client has write access
> >>>> - on a per request basis, checking client information against the
> >>>> one client that has write access
> >>>>
> >>>> In rpyc, there is a clear separation between Server() which manages
> >>>> clients and connections and rpyc.Service() and the service layer is
> >>>> implemented.
> >>>> In my case, my rpyc.Service() based sub-class needs the client
> >>>> information to be tracked.
> >>>>
> >>>> thanks & best regards
> >>>> Shivakumar
>
