All the 3 inputs are very useful. These address my query very well.

Thanks
Shivakumar



On Mon, Feb 27, 2012 at 5:24 PM, Tomer Filiba <[email protected]> wrote:

> by the way, this might also help you:
> https://github.com/tomerfiliba/rpyc/blob/master/demos/chat/server.py
>
> -----------------------------------------------------------------
>
> *Tomer Filiba*
> tomerfiliba.com
>
>
>
> On Mon, Feb 27, 2012 at 10:29, Tomer Filiba <[email protected]> wrote:
>
>> 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
>>
>>
>>
>> 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
>>>
>>
>>
>

Reply via email to