It's entirely up to the client and all of them do it differently.  You need
to look at the client you're using to learn about how it chooses a server.

- Perrin


On Fri, Oct 11, 2013 at 4:12 PM, SivaRam M <sivash...@gmail.com> wrote:

> Thanks Perrin for correcting me and for the link. can you guide me where
> can i properly understand how client will find which server it has to send
> the key.
>
>
> On Friday, 11 October 2013 11:36:34 UTC-4, perrin wrote:
>
>> Hi,
>>
>> Are you talking about a client library?  The memcached server doesn't
>> know anything about other servers and doesn't dispatch requests.
>> https://code.google.com/p/**memcached/wiki/NewOverview#**
>> Smarts_Half_in_Client,_Half_**in_Server<https://code.google.com/p/memcached/wiki/NewOverview#Smarts_Half_in_Client,_Half_in_Server>
>>
>> - Perrin
>>
>>
>>
>> On Fri, Oct 11, 2013 at 3:12 AM, SivaRam M <siva...@gmail.com> wrote:
>>
>>> HI ,
>>>     I wanted to know how distributed hashing works and exact workflow of
>>> any of the GET/STORE/DELETE .
>>> I have gone through the code in memcached.c and there is a pool of
>>> connections for requests . I'm finding it tedious to understand.
>>>
>>>    - thread.c which calls item_get () which uses a  hash functions from
>>>    hash.c  (I think this is hash returns IP of the server)
>>>    - item_get() function again calls do_item_get() from items.c which
>>>    calls assoc_find() .( this hash for which bucket the item has to go )
>>>
>>> This is what I understood from the material i have gone through .
>>> libevent has a pool of threads and when ever there is a request from client
>>> it randomly sent to a server A and from there after hashing the request is
>>> sent to proper server B.
>>>
>>> I just want to know what happens in these two functions and when any of
>>> the GET/STORE/DELETE is called how a request is passed to the correct
>>> server where key item is present from client side . Please correct me if
>>> I'm wrong in understanding concepts.
>>>
>>> Thanks
>>> Mothiki
>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "memcached" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to memcached+...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to memcached+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to