[Paperclips-discuss] Re: gnu-paperclips: session load balancing: invalidation

[Nic Ferrier]

>>> Gokul Singh <address@hidden> 07-Jun-01 3:38:23 PM >>>

>I would have liked it that way. Maybe I might 
>start in that direction.

Absolutely! I'm trying to do two things here:

1. build a generic API for expressing session load balancing
2. build an implementation for my own needs

I will not be able to achieve 1. unless we have people with other
implementations chip into the design.

Possibles I've come up with are:

- using a SQL store for all sessions
- using a master/servant relationship
- using a "last-location" mesh

Which one you use might depend on all sorts of different factors. A
TCP system would be vital if there are nets that don't cope well with
UDP for example.


>What happens if the servers in the server farm are 
>spread in more than one subnet. As far as I know 
>both websphere and iPlanet (considered to be high
>end app servers) have some trouble in this area. 
>Are we planning to accomodate this. 

Yes. That's why I'm looking to multicasts. The UDP solution is being
developed coz it's easy to do things point to point to start with -
I'll convert to multicast later.

Multicast group memebers can be anywhere including across subnets.


>> Concurrent request for a single session are NOT 
>> allowed. In fact, when you think about it, concurrent 
>> requests are pretty unusual anyway. Sessions tend to 
>> be associated with a user and user's rarely do two things 
>> at once.

>I disagree. If there is a frameset with two or more frames, 
>then there will be concurrent request from the browser. 
>Not an unusual scenario I think.

I agree, that isn't an unusual scenario. Doing it without persistent
connections would be unusual though and persistent connections would
mean serial requests. A system that causes servers to wait for the
release of the lock just imposes that serial nature across the
distributed net.


>Agreed. Then how are the requests going to end up 
>on Server A/B/C ? How are you planning to distribute 
>the load? How are the requests going to be distributed 
>across the servers? Is the distribution going to be 
>intelligent?

Request distribution can be achieved in one of 3 ways AFAIK:

- DNS round robin
- local director
- some custom name resolution

Some styles of session network work with all of these (multicast
network, SQL server) and some only work with one style.

I personally prefer DNS round robin because you can get just about
any nameserver to do that for you. That's another reason why I'm
implementing the network in a peer to peer fashion.


>The user-agent may issue concurrent requests. I still 
>believe it should be supported.

How can you support concurrent requests without getting the name
server involved? So the only way to do what you're suggesting is to
customize the NS. Local directors give you some of that control but
they're very expensive (and crap IMHO).

You're right that a request for a locked session should probably
wait. I'm not sure whether there is some response code that we should
return. I'll have to ask the spec crowd.


>Let us assume that there are three requests from 
>the browser. ( provided we concurrent requests are 
>being supported)
>Is then some sort of queing in progress or it is a race 
>for the lock?

I'm going to use a race for the lock. I need some lock contention
stuff that I haven't thought about yet. You could implement a queue
but I don't think it will be as fast that way.


>Maybe it can be changed to MUST NOT before the 
>final release of the version 2.3.

I agree that might be necessary.


Nic

Archives: http://www.topica.com/lists/gnu-paperclips-discussion

==^================================================================
EASY UNSUBSCRIBE click here: http://topica.com/u/?b1dceT.b2Fvl0
Or send an email To: address@hidden
This email was sent to: address@hidden

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================