This is a problem that has come up.  It does not appear to be specific to any
version of ACE/TAO or platform (at least UNIX-like).  

Below is the captured dialog from e-mail and a test.

I have been working with a customer and believe this problem is strongly
related to some other problems currently being worked.  Warning, this is
a bit long.


> TAO VERSION: 1.2a_p2-OCI
> ACE VERSION: 5.2.1
>
But I have seen it with other patch levels.  Have not yet been able to test
it with 1.3.

> HOST MACHINE and OPERATING SYSTEM: sun4u sparc SUNW,Ultra-Enterprise OS
> 5.6
>
I have reproduced it on Linux (RH6.1).

> TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> COMPILER NAME AND VERSION (AND PATCHLEVEL): GCC 2.95.3
>
with egcs compiler.

> AREA/CLASS/EXAMPLE AFFECTED: Notification service disconnects a consumer
> on every event sent by supplier.
>
> SYNOPSIS:
>
> A structured push consumer application is having
> disconnect_structured_push_consumer() being invoked by the notification
> service everytime a supplier generates a event it is subscribed to.
>
> DESCRIPTION:
>
> There is a supplier that generates a certain event every 2 minutes. A
> consumer is being told to disconnect every 2 minutes by the notification
> service instead of the event being pushed to it. The
> disconnect_strucutred_push_consumer() of the consumer actually is a
> do-nothing method.

The consumer is actually a JacORB server.  The version of JacORB is 1.3.30
and it automatically closes connections after 10 seconds.  I was able to
duplicate the behavior with a properties setting on 1.4.1 JacORB.

Here is a portion of the packet exchange between the JacORB consumer and
the TAO Notify process.

    Consumer Side                    Notification Service Side
at time t
              SYN (start of connection establishment)
 1. Port P1 <----------------------- Port P2
              SYN
 2. Port P1 -----------------------> Port P2
              disconnected_structured_push_consumer
 3. Port P1 <----------------------- Port P2
              No exception
 3. Port P1 -----------------------> Port P2

at time t + 10
              FIN (close connection)
 4. Port P1 <----------------------- Port P2

at time t + 240 (4 minutes)
              push_structured_event
 5. Port P1 <----------------------- Port P2
              RST
 6. Port P1 <----------------------- Port P2
              FIN (close connection)
 7. Port P1 -----------------------> Port P2
              RST
 8. Port P1 <----------------------- Port P2
sometimes the first RST and FIN are reversed

In the customers application, the Consumer detects that it missed the
heartbeat and re-subscribes to the event, so the process repeats endlessly.
That is also why there is 4 minutes instead of 2 between the disconnect and
the push.

What is happening at the push_structured_event is that the connection
having been closed by the Consumer is discovered by the Notification
Service when it tries to read the reply.

We have analyzed this further and determined that the thing that is
doing this is the "-ORBClientConnectionHandler RW" strategy.  The
default strategy is "LF" ("ST" won't work in a multi-threaded program).

Actually, there is a race condition, it should fail on all strategies,
but the window is extremely small in the others, so it shows up in RW.

Here is what is happening.  When things work "normally", the outgoing
messages are put on a queue, and sent by the ORB as available.  After
sending a message, a reply is expected. If an error is detected in this
reply then that is signaled back to the application.

When using the LF or ST strategies, the reactor is used to sense
incoming events on the channel, thus, if the server closes the
connection, it is recognized by the reactor and the connection is closed
and marked on the client side.  Then when new data is to be sent, the
ORB knows it does not have a connection and will create a new connectionto send
the data (that is what is happening for the disconnect event in
the scenario).  Thus, if an error occurs on a reply, it usually is a
real error.  The race condition is when the server closes the connection
at exactly the same time as the client is trying to send data.  Then the
reply sees the close which is not expected.  Now with the RW strategy
there is no reactor involved.  The thread hangs on the queue waiting for
data to send, then does a blocking send, then a blocking receive.  So
this leaves a much larger window for the race condition.  In this case,
the connection is closed by the server 10 seconds after the last
send/reply, but since the thread is then hanging on the queue waiting
for data to send, it does not see the close (FIN) until the reply after
the next send.  By this time the data is already send and possibly lost.

Rich

On Wednesday, 5 February, 2003 at 16:46:19 -0600, Rich Seibel wrote:
 >
 > I have been working with a customer and believe this problem is strongly
 > related to some other problems currently being worked.  Warning, this is
 > a bit long.
 >
 >
 > > TAO VERSION: 1.2a_p2-OCI
 > > ACE VERSION: 5.2.1
 > >
 > But I have seen it with other patch levels.  Have not yet been able to test
 > it with 1.3.

Okay, that helps ;)

[snipped]
 > What is happening at the push_structured_event is that the connection
 > having been closed by the Consumer is discovered by the Notification
 > Service when it tries to read the reply.
 >
 > We have analyzed this further and determined that the thing that is
 > doing this is the "-ORBClientConnectionHandler RW" strategy.  The
 > default strategy is "LF" ("ST" won't work in a multi-threaded
 > program).

Just getting clarified. Is this a MT program? If so, why is RW being
used? RW isnt too good for multi-threaded program either unless you
know what you are doing. Is the transport muxed strategy exclusive? If
not, you are asking for trouble.

 > Actually, there is a race condition, it should fail on all
 > strategies, but the window is extremely small in the others, so it
 > shows up in RW.

Hmm..

 > Here is what is happening.  When things work "normally", the outgoing
 > messages are put on a queue, and sent by the ORB as available.  After
 > sending a message, a reply is expected. If an error is detected in this
 > reply then that is signaled back to the application.

Yes.

 > When using the LF or ST strategies, the reactor is used to sense
 > incoming events on the channel,

Yes.

 > thus, if the server closes the connection, it is recognized by the
 > reactor and the connection is closed  and marked on the client
 > side.

Yes.

 > Then when new data is to be sent, the  ORB knows it does not have a
 > connection and will create a new connection  to send the data (that
 > is what is happening for the disconnect event in  the scenario).

Okay.

 > Thus, if an error occurs on a reply, it usually is a  real error.

Yes.

 > The race condition is when the server closes the connection at
 > exactly the same time as the client is trying to send data.

??

 > Then the  reply sees the close which is not expected.

What? You mean while waiting for the reply or reading the reply or??
Why do say it is  not expected?

 > Now with the RW strategy there is no reactor involved.

Okay..

 > The thread hangs on the queue waiting for  data to send, then does
 > a blocking send, then a blocking receive.

Yes.

 > So  this leaves a much larger window for the race condition.  In
 > this case, the connection is closed by the server 10 seconds after
 > the last send/reply, but since the thread is then hanging on the
 > queue waiting for data to send, it does not see the close (FIN)
 > until the reply after the next send.  By this time the data is
 > already send and possibly lost.

Hanging in the queue? You mean trying to flush the data? Doesnt it see
a write failure when trying to flush and the remote peer has closed
the connection? (I can accept this happening on Win32). I dont have
much idea about the RH6.1's TCP stack and how it works. Could you
please try this on RH 7.* or RH 8?

Thanks
Bala
> On Wednesday, 5 February, 2003 at 16:46:19 -0600, Rich Seibel wrote:
>  >
>  > I have been working with a customer and believe this problem is strongly
>  > related to some other problems currently being worked.  Warning, this is
>  > a bit long.
>  >
>  >
>  > > TAO VERSION: 1.2a_p2-OCI
>  > > ACE VERSION: 5.2.1
>  > >
>  > But I have seen it with other patch levels.  Have not yet been able to
test
>  > it with 1.3.
>
> Okay, that helps ;)
>
I'm trying to get a smaller test with less processes and machines, but
have not been successful so far.  Then I could more quickly test on
different machines and versions.

> [snipped]
>  > What is happening at the push_structured_event is that the connection
>  > having been closed by the Consumer is discovered by the Notification
>  > Service when it tries to read the reply.
>  >
>  > We have analyzed this further and determined that the thing that is
>  > doing this is the "-ORBClientConnectionHandler RW" strategy.  The
>  > default strategy is "LF" ("ST" won't work in a multi-threaded
>  > program).
>
> Just getting clarified. Is this a MT program? If so, why is RW being
> used? RW isnt too good for multi-threaded program either unless you
> know what you are doing. Is the transport muxed strategy exclusive? If
> not, you are asking for trouble.
>
Yes it is multi-threaded and the muxed strategy is exclusive.  The
original problem showed up with the notification service, but does not
seem to be particular to it.  Here is the startup and svc.conf files that
I have used in my testing.

$TAO_ROOT/orbsvcs/Notify_Service/Notify_Service -ORBInitRef
NameService=file://ns.ior -Boot -Notify_TPReactor 6 -d -ORBobjrefstyle url
-ORBEndPoint iiop://rich.ociweb.com:9999 -ORBSvcConf mot.conf
-ORBDebugLevel 0

static Client_Strategy_Factory "-ORBClientConnectionHandler RW
-ORBTransportMuxStrategy Exclusive"
static Server_Strategy_Factory "-ORBConcurrency thread-per-connection"
static Notify_Default_Event_Manager_Objects_Factory "-MTDispatching
-AsynchUpdates"

It does not appear that the problem is in the Notify_Service, so I am
trying to set up the test case without it.

>  > Actually, there is a race condition, it should fail on all
>  > strategies, but the window is extremely small in the others, so it
>  > shows up in RW.
>
> Hmm..
>
>  > Here is what is happening.  When things work "normally", the outgoing
>  > messages are put on a queue, and sent by the ORB as available.  After
>  > sending a message, a reply is expected. If an error is detected in this
>  > reply then that is signaled back to the application.
>
> Yes.
>
>  > When using the LF or ST strategies, the reactor is used to sense
>  > incoming events on the channel,
>
> Yes.
>
>  > thus, if the server closes the connection, it is recognized by the
>  > reactor and the connection is closed  and marked on the client
>  > side.
>
> Yes.
>
>  > Then when new data is to be sent, the  ORB knows it does not have a
>  > connection and will create a new connection  to send the data (that
>  > is what is happening for the disconnect event in  the scenario).
>
> Okay.
>
>  > Thus, if an error occurs on a reply, it usually is a  real error.
>
> Yes.
>
>  > The race condition is when the server closes the connection at
>  > exactly the same time as the client is trying to send data.
>
> ??
This seems to be the case that Chris asked about.

>
>  > Then the  reply sees the close which is not expected.
>
> What? You mean while waiting for the reply or reading the reply or??
> Why do say it is  not expected?
>
Mind that I am not expert on TAO internals, but what appear to be is that
when a thread has data to send it checks to see if a connection exists, if
not creates one, then sends data, then expects a reply.  The key seems to
be the last part. in the LF (and ST) if the FIN (close from the other side
is seen) outside of this time, the connection is closed and tables updated
with no interaction with the application.  What I see with the RW is that
when the FIN is seen the connection is closed and tables updated but it
also signals error to the application.  I am assuming, perhaps
incorrectly, that if the other strategies are awaiting reply they would
act similarily.

>  > Now with the RW strategy there is no reactor involved.
>
> Okay..
>
>  > The thread hangs on the queue waiting for  data to send, then does
>  > a blocking send, then a blocking receive.
>
> Yes.
>
>  > So  this leaves a much larger window for the race condition.  In
>  > this case, the connection is closed by the server 10 seconds after
>  > the last send/reply, but since the thread is then hanging on the
>  > queue waiting for data to send, it does not see the close (FIN)
>  > until the reply after the next send.  By this time the data is
>  > already send and possibly lost.
>
> Hanging in the queue? You mean trying to flush the data?

Yes.

> Doesnt it see
> a write failure when trying to flush and the remote peer has closed
> the connection? (I can accept this happening on Win32).

No.  And that bothered me too.  So I got my handy copy of Stevens and
found that it appears that if the sending end has not yet closed the send
will succeed.  The socket is in a half-closed condition at the time of the
send.

> I dont have
> much idea about the RH6.1's TCP stack and how it works. Could you
> please try this on RH 7.* or RH 8?
>
A possibility, but the customer's machine was Solaris and it worked the
same so I wouldn't expect it different.  If I can get a simpler test I
will try it on different machines and versions.

Thanks for your insights and thoughts.  I posted this for that and to add
to the data being accumulated on the more general problem around
connections being closed.  Also, as a precursor to filing a bug when/if I
can get a usable test case.

Thanks,
Rich

On Thu, 6 Feb 2003, Rich Seibel wrote:

> On Thu, 6 Feb 2003, Balachandran Natarajan wrote:
>
> > Doesnt it see
> > a write failure when trying to flush and the remote peer has closed
> > the connection? (I can accept this happening on Win32).
>
> No.  And that bothered me too.  So I got my handy copy of Stevens and
> found that it appears that if the sending end has not yet closed the send
> will succeed.  The socket is in a half-closed condition at the time of the
> send.
>
Another engineer did a little test and found that indeed one send will
succeed in a half-closed situation.  A second send after the half-close
causes the program to end on a signal (broken pipe).  This was the same
for both Redhat 7.2 and Solaris 5.8.

Rich


On Thursday, 6 February, 2003 at 08:55:20 -0600, Rich Seibel wrote:
 > I'm trying to get a smaller test with less processes and machines,
 > but have not been successful so far.  Then I could more quickly
 > test on different machines and versions.

Sure, sounds awesome!

 > Yes it is multi-threaded and the muxed strategy is exclusive.  The
 > original problem showed up with the notification service, but does not
 > seem to be particular to it.  Here is the startup and svc.conf files that
 > I have used in my testing.
 [snipped]

My suggestion would be to first try with the default ORB to make sure
that you reduce the number of variables in your system that could have
an impact on the result!

[snipped]
 > > What? You mean while waiting for the reply or reading the reply or??
 > > Why do say it is  not expected?
 > >
 > Mind that I am not expert on TAO internals, but what appear to be is that
 > when a thread has data to send it checks to see if a connection exists, if
 > not creates one, then sends data, then expects a reply.  The key seems to
 > be the last part. in the LF (and ST) if the FIN (close from the other side
 > is seen) outside of this time, the connection is closed and tables updated
 > with no interaction with the application.  What I see with the RW is that
 > when the FIN is seen the connection is closed and tables updated but it
 > also signals error to the application.  I am assuming, perhaps
 > incorrectly, that if the other strategies are awaiting reply they
 > would  act similarily.

You are right. Every strategy would behave the same way.

[snipped]
 > > Doesnt it see
 > > a write failure when trying to flush and the remote peer has closed
 > > the connection? (I can accept this happening on Win32).
 >
 > No.  And that bothered me too.  So I got my handy copy of Stevens and
 > found that it appears that if the sending end has not yet closed the send
 > will succeed.  The socket is in a half-closed condition at the time of the
 > send.

I think you answered this one in your next mail. I had a short
discussion with Dr. Schmidt and he opined the same way too ie. a few
bytes of send may succeed but writes should fail afterwards. The
blocking write strategy shold then bail out and do the error
handling.

Thanks
Bala


Balachandran Natarajan <bala@cse.wustl.edu> writes:

>  > > Doesnt it see
>  > > a write failure when trying to flush and the remote peer has closed
>  > > the connection? (I can accept this happening on Win32).
>  >
>  > No.  And that bothered me too.  So I got my handy copy of Stevens and
>  > found that it appears that if the sending end has not yet closed the send
>  > will succeed.  The socket is in a half-closed condition at the time of the
>  > send.>
> I think you answered this one in your next mail. I had a short
> discussion with Dr. Schmidt and he opined the same way too ie. a few
> bytes of send may succeed but writes should fail afterwards. The
> blocking write strategy shold then bail out and do the error
> handling.

        Normally a successful write with a broken read should result
in a COMM_FAILURE exception.  But if the peer *closed* the connection
(as opposed to crashing) it should have sent a CloseConnection
message.  The local ORB should *read* that message and it can safely
re-issue the request.  I do not believe TAO implements any of that
stuff correctly.

                                Later,

--
Carlos O'Ryan (coryan@atdesk.com)


On Thu, 6 Feb 2003, Balachandran Natarajan wrote:

> Rich-
>
[snip]
>  > Yes it is multi-threaded and the muxed strategy is exclusive.  The
>  > original problem showed up with the notification service, but does not
>  > seem to be particular to it.  Here is the startup and svc.conf files that
>  > I have used in my testing.
>  [snipped]
>
> My suggestion would be to first try with the default ORB to make sure
> that you reduce the number of variables in your system that could have
> an impact on the result!
>
If by default ORB, you mean no policy or strategies, then I did try that
and it didn't fail.  In fact, I tried removing each one, one at a time,
and the only one that did have an effect was ORBClientConnnectionHandler.
If I change it to LF it works.  My test case doesn't even come close to
the race condition I think still exists.

> [snipped]
> I think you answered this one in your next mail. I had a short
> discussion with Dr. Schmidt and he opined the same way too ie. a few
> bytes of send may succeed but writes should fail afterwards. The
> blocking write strategy shold then bail out and do the error
> handling.
>
I agree with Carlos

Carlos wrote:

>        Normally a successful write with a broken read should result
> in a COMM_FAILURE exception.  But if the peer *closed* the connection
> (as opposed to crashing) it should have sent a CloseConnection
> message.  The local ORB should *read* that message and it can safely
> re-issue the request.  I do not believe TAO implements any of that
> stuff correctly.

I also believe the local ORB should have detected the closed connection
and re-issued the request.  I just don't know how to make that happen.



Carlos:

I did not see a CloseConnection GIOP message from the JacORB.  Is this
message required by CORBA for transport closes?  The application is
assuming that it will continue to receive data, it is only the JacORB
closing the physical connection due to inactivity, most likely a
mis-guided attempt to conserve resources (in that the later version
doesn't do this by default, only when you change the properties file).


Thanks
Rich


Rich Seibel <seibel_r@ociweb.com> writes:

> > I think you answered this one in your next mail. I had a short
> > discussion with Dr. Schmidt and he opined the same way too ie. a few
> > bytes of send may succeed but writes should fail afterwards. The
> > blocking write strategy shold then bail out and do the error
> > handling.
> >
> I agree with Carlos

        Well, good for you :-)

> Carlos wrote:
>
> >        Normally a successful write with a broken read should result
> > in a COMM_FAILURE exception.  But if the peer *closed* the connection
> > (as opposed to crashing) it should have sent a CloseConnection
> > message.  The local ORB should *read* that message and it can safely
> > re-issue the request.  I do not believe TAO implements any of that
> > stuff correctly.
>
> I also believe the local ORB should have detected the closed connection
> and re-issued the request.  I just don't know how to make that happen.

        Careful.... if as you say the CloseConnection message was
*not* received then the ORB *must* raise COMM_FAILURE.  Otherwise the
client ORB does not know if the request was accepted, partly processedand then
the client crashed.  Remeber, the request might have been
"dump 10,000 gallons of coolant from the nuclear reactor core"  you do
*NOT* want to re-issue such requests (or design critical systems with
such calls, but I disgress)

> Carlos:
>
> I did not see a CloseConnection GIOP message from the JacORB.

        Uh oh...  OTOH I am not sure TAO does a good job there either.

>  Is this
> message required by CORBA for transport closes?

        Yes.  The spec requires this message precisely to deal with
the race condition you mention.  Basically server-side ORBs have a
series of responsabilities before closing a connection:

1) First, they cannot close the connection if there are any accepted
   requests pending.
2) Second, before closing the connection they must send a
   CloseConnection message, simultaneously, the ORB should drop any
   further requests on that connection.
3) Somehow the ORB must workaround the TCP/IP stack bugs that drop the
   last message sent before a write (you heard right)

        The client can use those guarantees as follows:

1) If a connection gets dropped without a CloseConnection message then
   all requests on that connection should raise COMM_FAILURE.
2) If a CloseConnection message is received then all pending requests
   in the connection can be safely re-issued.
3) The client should assume that any further requests sent after a
   CloseConnection message will be ignored, so might as well not send
   them.

>  The application is
> assuming that it will continue to receive data, it is only the JacORB
> closing the physical connection due to inactivity, most likely a
> mis-guided

        It may or not be misguided.  TAO does that too -- though not
just because the connection was idle.

> attempt to conserve resources (in that the later version
> doesn't do this by default, only when you change the properties file).


--
Carlos O'Ryan (coryan@atdesk.com)



Below is the only test that I have been reliably able to reproduce the problem.
I have been unable to get a simplier test to reproduce the exact problem.  Also,
I have only been able to confirm the problem by using Ethereal and matching the
packet exchange. (As shown above.)

Rich

begin 664 CNBonJacORB.tgz
M'XL(``#61SX``^P[9YC;1G8/:B"QE&2OZ]KG\XC2G<`M(+DUQ]7Z+%%K>WVK
MW?5RY7R*K#!8<K@+&P1H`-QRBI)+[[WWGDM/SDDDZQ1?>BYQVJ7WWGOOR25O
M!H4`"7)W95EW280?`#'SVKQY\]Z;-V!QX8QI/*U6%I?/9.%UNG*Y\=S4Q`0^
M\_G)_!0^<_FIB7'V]"_(34V.8F-^8G(,<OFQT?P$D(G72Z#PU;0=U2($;*JM
M4KUL=8.K:K93,>N-VR'3;;R*H?E?GCU]]MSLK>>1R^=RD^/CW>9_;'0*VZ8F
M<OGQJ?&IJ3S"C^=S8T!RMUZ4SNO_^?Q+*^N:3:J:12N.:6V3BFDXJF;8Q%FG
MA&ZI]89.2<,RURRU3E3;-BN:ZM`JV=2<=;)8G#MIDZ>;!B6CN=PH*:(5G28+
M=-,F9RR-UH@DVY22=<=I%++9S<U-!=$WZ:J"BLQ6C%52,RW.J-;4=>+0+8>8
M-=Z@6HY6T6E&D:2SLZ7B\MS2RMSB@N1*ZXNEZ3K.GH7RN.)JAD,MLT$M=573
M-6>;K%)GDU*#=ZZ<7B1Y950E"Z:CU;2*ZFBF04K4VM`JE$BJ427N,B`;>65<
M(2OKU&)RH'!FTR)JHZ%[2"B`P2P!M8&*T(RPJ@J2-%AJ,EAJ,=K4&BQPUG)Q
M:"@3*-)95QVB5AP;5<K1;0^'C9]N4(/UH$38JQ*;TR%2,L`V.4X1$0PG+)DB
M#;J-W9G:U*@BRTV3U*EMJVM,=2ZYJ-AM9)%:$4?>K+<-J.(U>B-R'+6RWB(9
M475E734,JO-QH;51;0,!I:1IZ-LHE8[VYXT<V;DS$>+H38W\M+JAOCY<B>RL
MFS9U#3OM\DNWIF?U>0;J6:>G.F:=R^<7%N86GI2D$KH1)["T!;6N&6LM\TJ>
MP-;R\N+B2M:T5NV-BIUU0<H>2-LK&3&)82L:KH]VRC'F&TN>P6VWR$=>R0B.
M;L[0G&5<I,B9>NTS-0UM.)MU68<X>T8A1XTD(R6C#=ESJ!EJK`56M%<^;(3^
MM!/9;+!1JGH&%1BRP!:7`'17?,*J]`PJ("`EGU<K)B%1RU/\'Y(TK]J.OCW,
MC(RM(7?1<\L9)G9`-I#,7YW>XI.2[GM(=+=_=PJ29M'"6V;OK^A-]("^51-N
MTJ;A244HPY!]G0:H$136*[G@KMDC:(?-J]Y@/8UUIQ0FY*\?*42LXK`%LZ13
M%9>9&W&0^#9YL4EM[E>S.*Y5G=9MEX@3]O6H]G6J(BGK\58,4:0/=/C\7W^%
M\S_/1&\Y#Y[_3^TJ_Q^=')MB^=_X>.Y._G\[KICY;W-12J7Q&@?-\__)'OG_
M!,O_)_/YB?')R3SN_T9SHV/Y._G_[;B.:T9%;U8I.>4G#D73=G.1HK+^F!3T
MIQ4E9!G*>KK5=4K%!`,3<:K6;88C82).ZKB+D-D/U5JK#+,\S"*#[&7CXJ6,
M=%DBQ+&V\7Z9X(V0;):P,*BINO9VC&76*F_E&XI"`>_E#<3'9C(3;M001789
M,,J9:8X50>5!C&-;ING@*YGA_811&WG,HK:I;U!."9F7+5K#O-^H4%M.A^)Q
M.D+:UU"AX&D*-TVX>0FX>.\!IVX(A4+94"W+W)0]V1346:8[*TH,O+G=[)>B
MXVQ@I)3SF5;CQ=PE1:NV](03PQ++:K-!Y'0D/^L85X?*ZCXXUUMX;('F9,8S
M3$6KX=[`I:3994/3Y3`5=X09<ME3385:%CEUBJ07-#V4/073D&:=F&_ITQZ"
M19VF99"\^WZEQ1<M:($KD[\%I*+CP$$$/2WM=PHXO=-0$(S$#^2TM8;Y$1H^
M9B^&B?;_VH;E\2^YL^@/!G<?.!3?O-HG6DX_96Z2BFJ0.;+:W.:[2Q,S5+;=
M9ME@S3+K;/-.WNK/?S"ND<=8=EOV><AIW$[;IO$XW_`:VRSK2@_[C'F^..P+
MA"HQFT[4?ENR[DE(+]>\97)ZZ6@W44\79\N+)11.I[0AYT=S_X>X2:XUX8:1
M[0>\69C=JE"^MWHSH;X)!P9\WJBHS;5UQROG4!^V0%RKC9INV'!#C!1%\0EW
M0/B,VA*-`II`!1VO'5D<'G9N6KHB27?R_5M]Q>5_Z@N4;3]O&8^=\K^Q,9;_
MCT^-CXZ-3[+?^4F$OY/_W8Y+.DXB-56+OMC$K;G=6O;V3%Z1M!I]D<@GY%9K
M9CB7D51=+TC)QVEEW23I"V:3U%&=I&G3"#K;O*\V-;T:V=(K:8:YI3D2U6V*
M26/-J-(:\0M9N/3]GQ@]3LC,:[*73!:;)?0.&)R/DV,M>*DXOU(N+1=+"![-
M57$#0YZ3DN&LH+6UX6B+9YXN<2X^C0+KFE',#.\^,[=`PIF#BRU)K-W'PM\9
M=+:2LK0\6YQ;/%\JM$FQWO:N=4K9#;G4AEQJ0RYQ9.GXR"V\I./).2^_KZL5
MRW0+TKA6UJACWV)6DK^3"$^SUY:MHSOR?V]::@.#8=F52'ERX?RN46-1?./)
M9*VF3FW%4<T]$76QT"W43>,F$`W3H+9#JS>!JIL55>\Z&AQ'Q31JVII2?P$7
MQM+2$_.GGRR1H1DR,A>&\_9\T=8V&*25Y9F'PUB42F6V\6+T,L='GI(D!EA:
M?G:Y/#]WQN6@LZ9@XQ)Z#U6N.5IQ?F%E;VA>ZQ+FB>JJ3MTBLR2=D$OGE_@*
M+*",:K7:P$1;V\+?SYZ=6\X,N_ULD6<R4O*$/#^W\#:E4LFPI<LUPW[-G_5^
MCICDQ./DQ(=[&@T&QX"6%DLK#!N7.G(M+B[TY,KZ;Y)KH)L8KIZWZ<K5<V@=
M7/?*B^S]DB2+JGI%IRJFB_S!SC[DY7.9T"ZHLWS?7A5O/T8(>;K!$'#XI51>
MP5=,$7EHN),H[O(*YW_1LX];5P?>7?V7G_^/3;'Z7WYBBN5_=^J_K__58_Z#
M0[#GU0WUM?#HG?_G\Q/LVR!__G-3K/X[/G;G^X_;<C74R@NLR!"=^VE,R>J\
M&F-::XI97U/:`K$R.-T-8KN(Z5#/?O=(_G05XWPON"<TW4'KBX?@24+/ODBE
M=<D=9@Q"-)=@`#X$,WM%,T,XO*7I:'I[FT$=CMEHKNI:!0.?:MNMLV7DS[^Z
M*#E6L^(T+5I=:MKK?O?2XFE>#O=PT1P=?&R86M6MH1.W]'?Q$BMQVR3#:N8\
M-#O6=E!]]!ZE;4PGZXK9=)0&(CFZ0>1TM*[^G.'7TDA+::S0H["*FUMA[VA7
M_$*[/4R,IJX'%*0P]VR6X.:`%:%9`F=[GQH$-4^^@:BX\^%AG&G66&=UF:I5
M7A[ECQEBT,VV/IDUH450[S7MGHRG,X$HKIJ(8;-"-0=2V&->,ZC<;<3>5QV\
MN(U#5[SJI&.63=XEXSXW.E02,:MHM3_:]Q35<:NB>"5FSJ0E:\<\R>DG38<L
M(SE?1062'F)8/E*@Y)H6_OP@^,(ET'-+4(I+L8%[#,-!ZV%U>I3Q,E=NI%,F
MZ7/;LXR8MS33PR2=)IDK@=;:J_]*3/&?D#")0*R92'-4*:'1Q9ON8.0ZY[L.
M5EI/DR&?A^*8WN3+F?;I\FR2?U/&'([[D5A-]<PQ\NU5PS*WMCV\.0;F>J`G
M+;/96&2?E3FF1;3:FMG`474#4$XOG"TO+L4;'"(]9>K,QKDP<U7/UKM`R;E@
M.+ZWX%XS^`C#?9L)%(&TRC73*OO]MLS%'?;9(;E.O51I36WJ#JGQP1#4#?L2
MT(-S1_B$V^:!^&\MOAZ)LMM?]DBTEMT3'FGW,<-]B-_'#EG:";L0)..[MZ1G
M'=2R0M:Q8':1G7VR9U2/M1S=%>\9=IG)0)H(<Z6"7L.AWE#D]$IQOI..5^0.
MRNB$!J(&EAR2%1?8[/+RXG*!6RUM^0%"J`M3<C!`K5AHEG((GX081[T<W6HP
MR=,E[R,=U-A)-X2?3`=SS&S&L3"&.+-;#8:"7L"UMTC/Q?RER`I>V6YXOH7]
M"G!:?1=S`0(CFHNE2N2`Q#`7-QA+>!+"0LX9-1.79\WD+%W]*[C!Y=;L@MA(
M=:L14E]D(7!@;][<1[>)FS,V,"!66[Q1P@S9PQ1N1>9P:X^3V%(E2DRKG2J.
MG1*+ULV-.&@^(2ZTA^22S75"HDMESGT033J"@'-RN8M2[>:J7;$T;N=EMN#7
MJ,SI#_L2?1`M#TRF2,-40SE,6WZ'`)$8Y"L@F919`M#K<P`6G!&=IQPM+^JZ
M"QY,,"/$#$YS]&WV;:^VP=J9@ZVXY>)@`<<D@9CVQ3;/A.2+Q\SX*X^]R!FE
MS&KL;"R!<I))$A<.;<>CYL8]S#_M]2`6^AZ$2\XMI]+Z.1-J5THKR^>+*^>7
M9\^69Y^=75C9*?!Q9CL%/A**?$L,H12)T<%;-)*$C#C9#A>U:7.5?>1>-D([
MFC(;?SG(!>36>(=]F>/M7":<YKQ6UQQF\127!C/BRU(R-FQ%C1UI)I.[MO(.
M$V*",6N(ZB?2$C*A'HC1Q"RBO9`AA<S>Q,#/<N>F95-]H_7U=20I]>`[A%(\
M]'++[%W]^],DQZ\'[K48T61@T;C:%>1;QI5Y3C5PC\<6@;_\Y-[II=5T/]['
MU1+>%*$;:!H^ZI7@ZY(B]VJM@RTIY.I(R->14"39B[/;E16X-A"W?U@PK;JJ
MDQ5JH36ZFW1%<8?%Q]#:8O*]956S=YH$3*?90)*QNML-OF9LF"_0JB=$IPPF
MV^%Y,07#17M4'(X+?CU$BI#;B;>[W%N2NW8;<K*S[F?4[.[R]/.69!=K>LYP
M:?"-EF9[$\R:E'5W/UK3MI"3]\)[RL$&JAO5JLFJ`'LCZC#'["+NS(`!WP1Y
M=HL09]_M\`_^-'0YN6E\G/(HN;D8"\+EJNJHWE=K"#$TE/$4&CNAL=@7M4L*
MEW:(I`O/.2UY8^`PR6L&\C$;2%[Y@"W:*]*5#\9#B=W4?WDYZS7PZ/W_O_SX
MZ-ADM/X_FIO,W_G^][9<K[[_W>^!_3`B')?@&2@GX2-`3<"J!!6H2D"A)L*:
M".L)T"00X7D)#L$+[*:SSKH$!I@B-"0X`N4$O,B>%KO9[.:(T$S`1@(V);@7
MMOI@&]XNP67XR`3@6O@H<)+PT?`.$3Y&@D?@8_O@X^#CV>T3F!"?F(!/2L`G
M]\&GP*>*\&D)^'0)/@,^,P&?)<)GB_`Y$F3@<_O@\^#S^^`+X`M%^*($?+$$
M@XS-E\"7)N#+F(!?+L%7P%>*\%423$"9C?"KD_`U\+5]\'7P]2)\@P3?"._L
M@V^";^Z#;X%O[8-O@V]/P'<PU.],P'<EX%T)>"D!WYV$[X'O3<)5N):$E^%Z
M`M[-GC>2R._[$O`*>[Z'P7Q_$GX`?C`!/\2>/RS"CPAPZ!3;2SPFP'XY\ZP`
M!XIFE0IPE)4E%YKU56JM,)>%'<Q;"W"_?'&>E92S.D:QK+O;GV:(QW<1<`5(
MA6.@`&]#:IAB9S'%SK95\+-!;)W>#0P3X;[8F"G`L-R50%LXY62D$B:-%<J*
MN0(<CIPRI6`92B+\:`I^#-Z+6FK[)%R$'T_!3\"K(OQD"GX*?AK5Q76EF=EH
MM5B`?K^C53/&N7"+QHS+J^SV,RGX67A?"GX.?EZ$7TC!+\(O^21#ZG=)(\G.
M"FT*?AE^A=U^-06_!N\3X-&P(G@U.!LIM0IP)%IJ%0"8)+\NPF^DX#?AMT3X
M;2;'[PCP<(_BIPB_*\+OI>#WX0\$>"#@R391V6`3Q>C^H0A_E((_AC])P9_"
MGZ7@SYE:R4Z%,S36E>*\"'^1@K^$OQ+@GI9*@I`I@.B%1!'^.@5_`W^+<#'E
M*`'>U&X<WLE.-E(O$N#8CE;(1O1W(OQ]"OX!_E&$?TK!/\._")#IQJ"CS".`
M,"C"OZ;@W^##<`#>CCX%_\X,X#^8XO\3]=DE#J;@O^#](OQW"JD(HK`O)>P7
M#@B0Z^`>/N#*=FX.1>$@<A(.B8*8$A)"4A2DE-`GI$3A<$HX`B4!^D(;DY1P
ME#7=%YO>"S"TASQ<@'OC4F0![I+:,E=1N"LEW"WTB\(]*>%>X3Y1N#\E/"`\
MB*#M^6A*&!`>2@D/L\XCT5PR);Q!>#`E/"*\410>30F$@>PK)%/",2$M0+93
M;V:]GNUZ2(:\0RN3YUAHIY@PHG+F_=6^Y"9C[*\HT[[=1IMQVKVD#O'D>%][
M=W1%X0W],W/C`CP6YY_=%G8PB)S8']`=C=K3F?D.,DPF.1#6=4N<8\(_JL(Y
MDC.=''#P[6=3`@S&B=_.E,-.MZW"P#.U'U<Q'\E+``*\18XGE9G?@1(R.\0^
MTS.J/#3$B!CO8:?;P`-^7<$3_L&/`"=C&,5/;F8'\=V#'+;!1U/QZH$"%-HB
M:8QO[Z[['5Q$YP&9`&=WI?W>M*8C2V;1LYK)W@2ZG6OAI+HG6P)\R`XR=".!
M\AR0Y]@<C.]^$.'IN+OC?$N`=W0F'[N49KY+W-Q1QY&S.!S4_?''7VAJ<@PI
M+S9%#M:0R'[<+\8YQ3CPL$X.1\ZK4+6]G4(LV>E(B%]9Q_7O)J5'VS:W`CPH
MQ_I:-JEOV56R&;\HY=X"A@=\M.U(2(!2#./8'&,ZLQM`=@Z%&AGI+1*?_+!<
M4NOT";/U&*N,JCPSUS4$NC]+[KG+*@TSN2?F-$:`A[H?6V"VYS.)GH1D@Y,0
M;C,[.)M.7-3007[6($"Q`QTC7=PBZA[?I^-,(+KH@GH\>K7V0P>,A3NMV0`=
M64WL87V'M7]LQW,#`:R=_%%(DIOV0)$S$1S06WN#[UCW9VOHYN)-#](H5_&F
MD<-J)SOO>_-Q6N]A;LSGG.ANW&'N1Z*G"YA)R;W6A0>&@Q_:$2C,)N&?66`H
MP/0?,YI=[JDQ,*][^]LW]?:_3[GY)GJG78`)D`J7?N-6F(_U!(.+<NA8S-U@
MT6^V"N&XQXY+?:56V1EEWT6,P1U4J/HM0#(H5F/X:*L3(\7N8<O+YEE\)CO!
M8'+C<CC(R\[HJ]M6U&EC>QJ.P00\PRMO!T%@U0Z\K^#;(_@46.O@-1#>A3\$
M.(_W0[SQ*"3A6?A0%W3_)1#A08!]S[P$^_KW7X4#@\++<'#^!ARZ<`/$"_V)
M:Y"\!M*YX:O0MS`T<A52A0,#!UZ&PX6#B'$#CERX!D?[[[H*=P\<N`K]5^$>
MI''@%;CWPOX;>.N_K__^:_!`J7!HX.#`H>OPX#YP\0<*8@C_(88O7H6'\>F2
M>`G>4$C<@$<N[+\&;RPD!\2!Q$#R.CRZ'PK2@'@="&;1?4(A-=#W7NA["8[U
MIQ%IH*__^'4X@3Q2[X23A</8[G-X,^-P.)!P@/5=A9/]<N$P2ILI'-G_"@P6
MC@X<0;$S%P:.#AR^!D.E@=3`D>LPC`3O&I`&4M=A9!_\3WO?]QO)D1[6W#."
M>!`DRMHZ1<DA:9%WNZ1$]OP>:D<W:U-+[FKNN$N:I*`[GY1.<Z9)MCC3/9KN
M69*7V$"2RT.,`'D)\F@@3T82Y,&!<+;@($\)8N0A!@P$R%^1IR`/08#D^U'5
M7=W3W3-#S?*\NBY;)W&Z?GQ5]?VNK[[Z!+M^(]GU&U'7;W#7OX(=OD'=PF?H
M]MT?WR_?+_^15CF&OMYX^Z]_I56_I6%G]Y.=W8\ZN\^=O7>_]G.M_L=:HWW_
M3[0FU&R]]W-MN_UK_UY[O_WKX3*]N=+^-O3]ZV^_^97V"%;JV]C[6\G>WXIZ
M?XM[?_O;?ZQ]T'[K[;?>_K6OM._?T]Z^_Y766=&^TAZO:(@7OP%U8;S?_`/M
MN_N)WMX+.WN/^\+Z._#G'P)._B?MS[0_U[ZW\N;*NRM;FK$R6+E:^2G\_:<K
M_WWE?VAM0+OOWGNH?4^@YY]K#?C?-[6_K'U;^ZO:W]3^CO:WM.]JW]'>T_ZV
M5H._]K55[>]I:]HE_#J&5O]<6]?^A;:A_;[VKO9OM2WM2\W0_D@K:_]!J\#(
M=>BOI?U/;5O[WS#2_]&^#[C?6?E+,*4WM=]<T;4=@&AWI:OMK?R6]M'*)UIW
MY3/M!RL#;1\@/%CYE]KARN]KQRO_6OMDY>?:3U;^1/MTY3]KGZW\J68"Y*<K
M_TOKK?Q?S;[W+<VY]U>TRWM_0QO<T[4AS.:+>SO:^-Y'6G#O4)O`S'X44N7W
MM'M$@+^*2_0A+9&DS!)\TK1KF/H-_/)C[;>5)M^239ZD-/D'T.1WX)>?:)]R
MDY6_IOT*-?DSA;QV<:.^U/:^U)Y^J3U3:"RL\9%:H_NE]H.T2C],5-H/*WVK
M\P=:/:H)E9Y_I_:E]@(JW#_@5O3#88@M/[NW\AW\]3_^J__W7P&MGB?0:C.L
MN,EH]8>T=/]&^W<ANCP`/J9I_Q"0XA]IS[1_K`VTGVE?:/\$T.%G4.N?:O]%
M^SWMOVG_#&I_!O7N:7_WC@Y!?HF+>OZ7R.6VM#$6R?^T7:GA_>]:I<C_>B<E
M9_\3E_!NGP=JQOW_6K/>E/?_:[4J_%ZK56K;Q?GO793Y\S]%&76<F=F?2G-G
M?Y+!5<M-_@0=/I6W).*I.`T1MQ$;(25'U.W20\W,#/7BR1*20L'LGHD@3CZ/
M!(O2R)A0>+<E?RYA;"L/$[=8VVWX1+UQ:&W*UPAH+QW@'1D0BQ&Z0S9_LX82
MUC$G.SK'"$88=^MQ,LI/9,TY'V\]3L;[A2%[')R+"7RCZ\=X,<ER`UXQ!:NC
M!#RFJ$(AP2F3.;+/@1O@P5H@4U7:NEA"(W56O"/=/N\)I>>*XA<C^.6U(_W!
M%"PREB@G29?)FTT].GT\*0JW>!T'I:GHB;E\B'0"\Q!YC!/4DH+57S,)678.
M,J8/Q--3@(FN%FW&)Y>.6'@@37E+;#_@H$Q&=XKAU*,?^O!][-TH.)*?&.DZ
MF1G)OLY/?12E*H+>7Y-L13GR/^%GDE^!_2^H"<R0_]5&*RG_&]5J<?_W3DHD
MW[.W&Z1]*?,KI:9+_[2N".M10!)\H]3&?YG*)Q`=P!8HU[A-]Q90/P#JP2C=
MO&%S`A^B*/Z-4H"G62%]<]Q`2.6LBI1R!:>9)SGU]57@^4\F8_@S8$:69/WB
M(W7:X_^6W#^C:BA,];@TS9?*HN^MQ^=V@')27T]M%)=$XH]D<_[=!`[.G9!(
MZ=L),47@4?L(QGEV+N4,2U]G3HN'<'K"PPI<67IVC^TO]`<B]=U<=3>H:BX.
M;(8R+CPU:+=%Y%#8&>&D5!U?![X^;[D5_[]8;(Q9_+^Z74_P_WH3/A?\_P[*
MFDB[QN>HQQ\?'NYW]X[,KOF165J##XYKIWXKI1N.4V=\QV02<D*$3(32V_)J
M!K*T!"G&3_!D(Z!';M(.=7TZP)]@@`3?D5E$++%"]](9!Q-K,/."C"I?9O(7
M>5LPUGDV"YR;M?$MF<T%&\DKFZ4Y&&,\`]0L#HGI+\8D'MH9YKOY0>EWH-8:
M)^_[)G'1U[?,X_];7../EQGY?VI5?/,)\[_7F]O;#;S_@3F!"OY_%V5.-A[W
M!:;4!9Z04R?%GQA^YP[D`S5JZ)^(=D.%XW%I#D_D#!-&:=9NJWZ?'#M%SS=4
MICR9TW8$J,[FG3OAQ*#3Z>2GP.-D/0QA=`%VELV3E1E_.F%ZU']FYO>/79P'
MWA^FS#;Q]$&)1.GB-NYL9ZL8M[=P)OXDP,KLA*8A%0YRPEJ84098".8W\BA[
M[4-*^QZEK)R^$"VZR/2MQ3QI"[O7F)!2Z&A&KG]&TOBZ96?Y3^420MM(D"]M
M!U.WO&:B;L=\O>0[F%/P+C;@W+A'K>1MF(PD_1(34\K,]1%_=7=UI_]!K&*H
ML/V6=QQ=(M`E^7WA^1GUJ>>4%I3R9[$=HZVR>^'VQ!=QZ[$(-9:IG=85X*0>
M&AL]_+&?NUGZNMV;8X=@]""17V"*.\3V($E#\WNHX]FP5."GZ4-Q5LMIS%YU
M^A=@`2T3H$)NY9FYJ/*I222DF@,[I<"D/PD9I*7#^QDBAMW;>BQC\645D`MJ
MLJF9>Q[O>EX*#4TO:I6__QFSI%A36'O9%?5D4HX*4U+ES/8RDI0E,K4-KUO)
M58K/<.MQ9O1PF/4B?R.34<^;B7'B$U&7/]OR?E<>+X58A&E9LFUG5`X$DBLK
M/<=Q5^HYEQ@\\V@K7,&<DRUYL+7Q06+3<KP'L<[3""BG;22)5.BF"%_NJ=B/
MF52:$@LM<:S=%DU--3U+B#6SI:&^GH!F;FH+@5*3!,G.\JDO,21(CQG>E'`]
MF52:$@LM<:S=%DU--3U+B#6SI:&^GH!F;FH+@5*3!,G.\JDO,21(CQG>E'`]
M$Q/*.:73']`I73ADZD$=9S_!\SB,,\"G!_!Y'E;._$M[8`?P'W0XR,ZCF)WP
MNS%#`7TWXGA"@/*AYU&6ZUBC^/,M,2]*?F$?CHB6F`!U4-#RYFU[$$\X+M2>
M6CZ0C\DLT')C@;KS'<KTO$D0/A2#2XGO`8E7:,+%47<Z;"#N(;=Y-&H@G[-,
MJR[Z5ZO+W5.J)TP]:09PGIA==)4ZE-H>?Y_2TE+SRGP@.UDTH4NZVB(>UO"E
MPK*47M=5C-H0JR@&6!;@8#55C>I"8(<1_<M9BNR>AC=4(Z8$PJ[[&&\`XN?[
M,OS_<5OW109:T@7Q95.Z"*",GYX()S+MTA/95$3"FU3PG@))K,YJ3G``*G?T
M^&Z&1)33/@2RECM*-0](08[Y<%:SX118-P^4]=PQ:GE0"BZ0#V4M&TK!,CX(
MT21=#*8FT>!<1VJN*BGQ\KWN^H.IY[M$%<&7J%(D+U?S(UB^IJ3-"XE!^:N6
M7[3CLRA4YO3_+WCB&R^SSG]KM6UY_MNL-"N<_ZF(_[F3(L]_G^\='^^]>+9W
M%#OYC?\Z[YGOL@X+6!TK9;Q!>TQ._7+Y"9TM*\@J3IMCH9WA`;,\A45G>E@A
M=IA<+BLGR7KI5V>=%`C5L%S>M:-6T7%OB@'!+1(&1(K-D&<-9.OYTQH\:N8S
MCZC5L]O4HUO]-J8K1SW%12`,AL?`\ARX_&X<S73]W7(A'>ZJY/'_9;T#.>O]
MQP:=_PK^W\#[/]NM1O'^XYV4;]#[C_C&FWC_4<]\`5*??C@Q_)((>`A_SPV$
MGFX=79<"Z:&7Y--S-`L)8_2^I'BY+O:^I'S7+GQ@4CYO5SPP>;NAB@<FBP<F
MBP<FBP<FBP<FDT75_V"KEO_XH[;@_>]Z%=]_K&/\=W'_^]67K/V?(J&O$0(Z
M(_X3MI[O?VW7JHT:WO^O59NU(O[S3DK\&O<S.S`/1D$BWG*6LV<UMRX[>[+J
M2&?/:BD[CC-T)G`<IW1./=DQGW;W3_:.XL]@80C>:ECIY,F^^>QHY_ESK(9O
M>=']=#WU?GK6]?2O<1%]WH#+OZCQEG&/?BSJ+1XG<Z>!F$70Y&L7-)F"0&FH
M=+L+Y:GA>M.;9?<.EKU=8<3DC.@>M4VT*P30/.$[<\5'TF;DA4?.WHN9<T_&
M+>;5G16VF+]BZC.:>:/$DG7&W<TB9E%NC1JT./5`IJ@S7^AB?(1YMR:,#TP+
M79RQ-RG+P"O;;L<R`],"G"$IQF(UTQ,4Z\ET&3Z`,-(M^2B`Q3E&XG#G`<'+
M;YGR94T!`<$31@^+C^N*9)ZUW++'^8*$,>.'&(3##&<O=<[RQA((XQVZ*/6P
M.0"=,&)3B0]3;"SQ'3E:%-#BA]4KV=65G\0#H%/<$!9/JD6Q:$2YA%N/IU[4
M3`R4&L3(I,2-Y08FMB6%5-,O(=*]Q7!5\NN*ZXK1JE#CJ:45U:;6,&J"RQ>/
M0TI;.WH8,]XH-]!(;9&R8%N/4^]YIKZ>F2&SQ$T>6R'H1>\199%5U/4<=.5$
M^9F0)V"BFUED%0V>?Y-)M)[G0E,(:W9L<V0LZ#+33VH:G]N&+#^8%;,<HL"2
M8I93CU)3I&=.TV@=5>#2[S?-")J7'22"YN?L(!9_S8VC*&R)?`D2FIES^Y91
M\^DS2;GOI9\`PG/X<W`!,O'*!C//EDFI@3D%GI$W\YPLU_$@=QJ#QX__AJQG
MX;XSHL8S@JSSKVA0T_FEKQHVKKXJRZLXK^83@1:'(SN2/+Q'D1D:/R/;&+(9
MD9PL/^L8_8]2.R,%F9J(:CH354S_(G:9'WQ7BBU[,O0NOHS4G1)]IRM%]5UG
M^?^R73"+^P%GY7]L-43^I\9VL[I-^3]JK2+_XYV4>9UNF5^G0MNC3ZGWJG5]
MH0Q0>M[(Z:&T@JMD)<1(1N(_X-!;T6J.5$%A@:X%2"AZ=\-\(3;=$2GI\2@M
M"AO^0)(@?Q7W#T"U3IT*/N`;(W)Z8W7B^LZY"[R5'EOMX%.KW\\+BD;F@T^M
MZG]?J%KY[Z7JCQ]W.')=\!4)9OYSK#B/3\G4HK:Q^S>9A9=!RI&I,X<V</X>
MJ+1^M`KZ7(@QQZ-HZW/MN-S()>8'FR]!6"E[T1;,&G:[M&'+R1NV0.*PN4M6
MAC%U_]5G[A9,JZ-DO5D@P]C"C",_V1@=093++SQO!*+[59XU+R[_%P\%GYG_
ML=9*YG_>KM8*^7\7)9[_Z\G!B^./GZ?G_XI_6T+^+\52GS__EVR4R/^UD`Z2
MEI`K5Y685Y-0;=0E*Q0,<PSDV%N>=YL\;/DL+V5^RQ/B16JRS)(9_[&LX&]M
M=OQWO1'R_T:K1?'?8`(6_/\NRC<H_AN#(47\=VKTDHC4SM9LO)*,IZ0197]1
MK+8(Q]331M"C:&T9M5D$:]]JJ")8NPC6+H*UBV#M(EC[#HJJ_RU3YU/+#/VO
M4:GA_;]FI=J`_ZE7-'P1HE[<_[N3\@W2_V+W_S(N_[TV-_]^X<HLRHTI`)21
M$TR:=$XI:WA$T8$R(HNJ^(C4>N9-QYCF'%.;LW7FF,(<TY8+5;E0E0M5N5"5
M"U6Y4)5_R8NJ_Z,F'##B^(;_M5(^Q0KJ_]O-[/N?V_4ZO__0JE7JS2J]_]NL
M%/K_793O2GE5#M]CX-LQXKI9XD_D@*YO.-Y8WP*4V;5/)^?[]DM[H%?T!R5_
M8-LCO59*Z91O%H6=QOZDKO`!V"/0_Y6K;ATT1MOELASP0WSK=$NT/3D\LND:
M@][2M_K4A7?Z.;!T/[@!.V8R'M!O>V[_T*-`&<<;05]CIW=A>#WGRCY%]:/]
M"`I5/'[9`ZYZI@^]`./LSY3IY+^+/"_TV<N5>^_V]MW/M?\Q^U^.;3C]P1)Q
M;(;]7ZG%WG^LX_WO5KU:T/]=E'(Y>F(5M[U$]V/M\9D%=*DF2`.EYC0E5=FZ
MX\J\ITJ&LBP-**H<IBS+KHIA9Z*V&&Q#I`[[12_:-ZA,R7]ASB]1_,^4__"K
M]/_5M[=)_F,:L(+^[Z#P=I>3=L3MA$Y!F*]=F:+_I5(^%Y+_C6SYOUUI"/IO
M5(`!D/]_NXC_OY/R&NG_K[U"+KM?*L^=5]'/*"K]\PC+PJRHS*#_:JW6H/Q/
MR`I:)/\;]7J1_^=.2O?@J(W[0W;8J3B0?=1H-'IUJW76ZK>V:W;K;+L&_SYK
MU.&_Z@V[587?'[5L^DWY"[^W[.U&J[G]_G:C0?];M^K5FET7`U1BY?V&Q`#X
MOUI%@E&!T1ZUZJWW<63X]Z/M[5:S58._L/]^I5+O5\XX<%`&D$-3^*5A-YM-
MV64S'$9V6Q&P-IMU@+"VW:)1HGIAS<QZ"?@K[T^-<-:H-AOR[VHXO_<KIV<-
MKE=5VC^BF4^5[5Y\74!`\N\M@*JQW6SUZTA1CW`=<%WN=AV@YJW70?EWSCK\
MHFGBEZFH_/\:C?=7,,9L^X_]O_!;I8FQP-5&K5'P_SLIR]/_"N/O=2PJ_4O7
M][+'F.7_;6+.=]+_H&*MSO%?!?W?2?'Q(;R>SB:(>1R,K<`^OS%%.BE]%:F<
M/S[ANSB.YWYDN?T!&$+[3XD)G(PMUQ]YX^#YY%IV@$\.#2:^\])>+:U]G3&.
M/IEK##$$&X!90W@N7U;M82*/L6WUMT;V>*L7CAEV(\S379$UBT*K3)DG@B_"
M^DK?ST]V'7^$J1LH_F+'OW%[%Q^/^@"#O_H7G"W&Y3_->^ECS)+_=;K_B?(?
M5,T&QW\VBO.?.RG?B*/:0A6Y=8G1OT_L<^ECS-3_0_IO5%H4_P'ROU'0_UV4
M5^)*+>COM2DQ^I?7JI<\QFSZ;T;TC_F?JLUJJ]#_[Z2\BJ..@OQ?GZ+2_^=6
M#S-ECOA%8\?VES1&OOW?J-5;+?G^1[6*;X%66ZU*H?_?25E;*ZVMZ3IC@,YW
M'R9COC/@\04NJ%""?^8KI;7YXMVY8I<39NE*PJPX"++B?#W."V,)._WX:-_7
MKRY@7+U[<.133D\?C!3,-CSQ*;T:9@8QDLF]Q$,)ZQL;T,GN@;ZWVSW!G+B^
M_8Z^?N`.T+G@^3;G"KWQ)M3Q:&"Y+GH'`@_CY#:AJ7>&F=7&4/.#K0V#0,)$
MHPK'55:%$HY2<LV^#LN">T71&I.1'CA#VX"51!B@CY[E0WWH'-/T"EA]_&/H
MVS`-?Y,OX0VM&WU@6YB\5+FKIY_:`"3T`M@.(-_@6IS:/6OBV_'^`![W8:##
M\#=VL&$@Y+%+?]`%@GQ!7IR^SBP%E@:O0G%WK@=?Q\-W8#.B*1NJD$%F9`V\
M7KM=;56,1M.H5N%?U7;]_=:C>ODX@+ZL<?_%<5DVLL??J^T>'NR4S3&8GYG]
MLO#JM<LOCDWX5LJM=N$-[;+D#;*%VO/)V.K#FLE6%T&`MNO5U95Q;=P8/RW_
M+H9%EK&6/<:VKXJ4H.Q=HX>,$8N7CC%[JN)224FW!@/OBE(3#H%Z='2L43[8
M$`BBM-,;P+G1B&@`,`G;]2C7CT@)=VG?("Y:+B#.J1.,K?&-C/[$^K(MM(.M
M@/&NO,D`$,L>#YU`[Y'WD-#>HN<B)*9"ES02)A'4';R:BIU$F.6,K'X?*-QO
MX]*YDV%900%H^<(+[#8V!))Y<7"BNS;VA+`!K"(]%M&3$)HWN`[0#D&.P4%\
M)B(E:`'_W_>@N37`%;M!=B,HV.O;DH"!)!V\+#N$Z?']+Z@@+M"V83&$R*9_
M:!U_:-\\MT8Q1$ZEE*V(3N;8[-F(PU5VT)@\IT<>,&<O8F,*GGX]Q"L)1FE%
M8P$F`4N"_Z<,58',UHPHR:N"C.T"WV#`MPW&]A6@K#'=#>P(,57FL5CU&GD7
MS@)6&;!DY+E]YH^(J?J%!UC.VQ9VJ[]T+)`J3N^"?F9`>H#5I[9`0[O/S/Z(
M096HBW4$GB)62&J*P`-TL4<V`0`U"$\424DL6'\H\(&3;?-M9*"^AS@U!$>\
M`X$D$4V;19*A/X<O#MX!!Y)PL$\@3G5XGH4R,"P.+K%8<W]RZMHP$28QDA;T
M"]89(CX#(.E01_5@4?T>$%(_L2T]:]";#%#Z(?W?4.\#[]SI(8AB203!V,&5
M-[XD00/_/;3\2TYFZO.J/Q'+;1&GZL.NB13>Q'FB07$;L3\D5^(JO$_0@^\`
M>8[$14J=@N51ZGEC@V_2B\UV7,"E`0H_@%=.FI''BIJC((]2ZX_UA][XW(CT
M\.L;WDJ&NAM5?!@I#&DSCBM1D4)/P+%:![#=\':2LH/)N^6VQA82=X67&Q>;
M5P'4C;,8$Q,<#VH,?.Q*4MV5`[5<I;W8ZBL'*,7U`ERH:!>B.:7A<7?W8<1E
MQ2*G@HZZ%<L4V"DW<)@I$Q#*!H-DI&D@%+X=\'0$??A,X0\C=O;0T)\B>H:4
M`<+)[L&&0N<L'6`*WA#8=!\A`M6/EL1!QL/=>[H/JH3N`1ACQLC\Z2*K5B8L
M")AD"B!4R&'BI`SPH9@#3>\,1YR20NL.H/)+RQD@\FTP&Q%ZI%$*I4D2C$ZT
M#JEUNKNS:KQ@O.S4FDU#_E/)JHEHUU%4OO2*P$TZ61^VMG(_+5'@(?WB=4DD
M,]`>3O'-F4DPF@1+%GBP;YZ[21L*0S[TDX.2!H*\"!FDY=Z052"KX]>(R?1+
MBM)`C4S168?4BZ6M#;F$Y'+<PJR;=VV01:]_#FB]H8N930)G8#S9V44:.+==
M?';*9OX.Y#1VX"]H!I,^]7PDX`&ZK>"7"B9T/@/U7J_"?X'>A5P:'PODVT><
MR"%FX]2PGHL"SA(",[ONXXY>A^I]7)4M&E*NS3H:8[A`TLR:N-85"B@T'?3V
MUH;<L1#D3A4GSL9KWT-[CWLZ]WY#/T&5&$&)^%E(#"`ST:SI[!\\>]K=WSO<
M.?D(.[JPK_N3X0A[.?>4^U:^')B`-K".*>O("V!^!Y=,Z<1Q@1'.Z$36270R
MM]FQ"#*F(Z?^R<[1B^Z+9VUBP&<>VC`(M"(K_0LR,:(FGDLB4P>!%;!<Q\VR
MK[$![16I,S?J*$).#>PSJ.$&WJ1WP9Z%H8>)X=%6?R<!V()S67S%YECG69!P
MA0\MW^D1@WF2H.[9<YD->4DH%<^Z!X<Z(`LJ97&FQXHK"7?7OH*]D1X2M'HE
MUIT[WLBDYB&;JV'7DENCFP7,3-AOYTR/8D%PYU`U8-U$[+N/2IOC7T0\5+3M
M-(D"P"P=(O,=@F[@&T"9^%;,E>6@GA-<V;8KQU*;WYBD0X)*T&E6*B72,']*
M2J=4P4XGF.G79WLFBT3A`]0SL6VG5FF\CQT!N=>PHZ%U[0PG0]$1]\\/EX18
M3#``UT#]FFN)ETVDEL+*'MK`;(Y/]RBT'D4UVX3O@?XYYH0B%1!SX,!_R_G)
M>8F&I!1"RTO@F<0^!8A"K^;'"60ERE\LK'LWA)[S&"//ANZ;FZ!RT<"86D.T
M!]([O0EL9,C09^W==]>;[\%D.+BG_^'D[!B`VZIN&#JFLR**=VU6,H%I04?"
M?$<!PAV>A4Z^/@R#6X-:K[Y_<'*,4.SO'#W;T_&IA.A9'+1%J']D_'U;=.N0
MEH@9:PCH^#;`'`94BQ8QW"5T#PR!'P':`Z1`?ZA=PGJZL(JV=+8,"7/0?$+7
MQ-A&:T^BS=3<.U5"G4\0:\F(&]D]Y\R!)8@HAO!;V&MC>S1@SPWE#H/]1;6:
MO!0]6#A$`DM'J\8;GAN4>-GH/C\T][O/NR>1@`SWE1(YNQ(Z86X(L]>DL4Q4
M;0#;.U4,&4=8N=86&68*!3M]?)2(*V^2$NYZ\/_N%MA/'BGD@3?"E033Y!*7
MRCK#=^U\3R5BPGY%5C`9."[;XC9CFC3+$3X'7:R.`?:T>#M1@",HPQI`_[V!
MY]N;B#I81X"H.[ZR9D@X`<EW4@1<R_6OX*\^;2`MLQ_N832(6#`3IQZM4T6L
M$^PUZX66SI$>A"3H-E%6#<2?BY`!\Z-PM@M,'(4*S!SKP+3&T,F'(8AULMT+
MLI4=(*D+-'MY8DB5M4#*\JRE+!!/?&IM0GXL/.YFSZ)H/J'<"#MM2DVX"<F#
MS3/.<\_&F>.S><H.P;!G7?1LZ)_8UN5'EG_!GH`)NNWQIZ/0ZT_\"Y:0),8:
M:+*@X/4>HOYPQIP)AXQZN!`>,#D0&X!#9I_,[V"0L\E`\JP+ZZ7-N*Z<-"!=
M7(#BNS5P7N),D6!&*#C]@/T?1,/2P@=:)\0E<$++DE@#:N1ZU:@1*[=.O9?"
MX#U@?P`;PA>4&PW9C'!2*O-AY&2<"L$#)<H9L&9P0SL/ZM?`Z3G$__K`(X5F
MAJX(!-\4?'-]PPBQEE<!.D$PH[D1H`///9=3C\\4@1=H<B%A-&G#.XK3ADR/
MV,Y&:)ALABO$#:+*PIXAI0<7#X45L,\^28+Q)7+\==_![67H:D9CJQD:"-#4
M//6&4B4'(:DZ\[K<:06Q%\T`GY[T06P03]JQZTY4JZD:E($/?U;-BBF;BB$6
M4#OG5V[5NL?`FP'O.=@6R2RG[AS]+@`O=+PC'[4&S,(WE_21%:"BH=(VTSTJ
MGL0]SX!F$6(V`)G;H$K'/TJGLUA94/`,_A(^R3O3PT7^0VX40D='C91Z,SPL
M8!JC%Y?I8(_/*OK1*4.4Y4/!7OQ'OO[-*R^BG-,`9TZZ*/RZA<O!XN=.ID%#
M)2<3DO+T%G0R.A+1X+&>XMVD+<BLWJ:A(R:YXZJ$FU@G/*?@TQ7A:^0C.#]"
M1]4<XZ-FJ;"37NVX]-]TLL%:'2OAZJ;%O=EB&U$"\V./X7E',+;0KK+XY"-V
M:#+&ETF@'S;3R!L:GXEZEL"G**&`!<M'L<7S=\S`T0Q\FWIF'>OZ+IC6A\XN
MF8V\>\3+[XYI35QV1`N7MGJZ(.3^%1I(PGB>!A7ZD.JZ3!?950XYQ-&WZ/()
M"C+CU`$SF0(DDNBN:%XT4G3!0^ED,<?/K?:$O,"Z..M%[M$].+J[/2'C-KC@
M*)$$:HOC@Y'G^PZ_HHK:C8V4);RW5TB9W<,RT10=Z`O/%"PN/HV[R?YAK*ZR
M$S]L`S3\,)!4#)77;0/43V(68^OLS.F1U34YOU".1S<2EH\\[2%C?K4/3&.5
MS!VK!]1*BBI@%OI`4*=$S1/-V!XJ%1XAW3C.E-XIK45:M^.)EUW-"\\'G=RH
M&76CD?(99]-I;%>KKQAC*`Z'CY!V^M8(K4(B`3RZVA$X](JIN'L88BNH%4,\
MFMW"6)2^CFNDK]-^8$9A8,@8,(`B,3KXBA1F4'M?')SLM0%N[`SP;>#`SE1K
MVT8%_N]'TN\B?9M\!$V8>#;VAJR;XQ'2D,P6&S;N8*>+BQ#MT\'.X9P;D[=B
M\M"`Y**NL)QHK0^%"\0F)$/'AN.^,V,C\E>^M"BKDW9**K>3'U7@#:!8Y>\X
MVUO4?;N@AU@$V<4"2/0C>X1G"*A()-VVM^A_8?B/@1."=0SF`SF-Z*4O8F0@
M%43<0'=XA$@/Q@G&``E5$4\IMR8CU=)QAF-IZ2B]"B'7]Y#I25%W-08+,>P\
MD@-H[?(`Y#,&W@AJ/L4`0C?30VTDAC=MMS_".TM\=(:-Q&'OJN>N;HJ^A7+%
M$,EP'V*4H%RA?7^#TP7@'#05@`/3T0!*`'9?PD";3*7H`K`F@8?'33TZP1_;
MYVB]CE%A.T"3^LKA\$+H^F/WTO6N7'&5(_*UT5DRNME"#Q*,8)`.:6+OINQ4
MKFYR6@(HABG@8*A5]#:NBDU+LJ%-LMAA#5C8L0<;&O$#U2*<0+'SL1)ZWX%0
M7MJ;^LG1SHOC[MZ+$_9BI`#?N[![E_+Y46SDVKZP4958O3@E1(20%;4'N$+Q
M?NI(;,#3*=IOMS^EOXR^%:A53JW>Y63$=7[:_I3_3%9"J48U.,3P%##5*I^.
M/=\N\\.&YD4P'(0@J!`(WY7ZF^N9WAG(1\M/^5E@80?I!,E([SX_FHIP6L>'
M'UXZ`T$P6R,1)[*A]H<U3;88.O$3#\`$)U1,0ORPG&"3739Q)R.)%LN5P0LB
M1SD[+VF'^0P38T)"B8#N^DJE$M_VL,O0HU<3SDZ&(<;Y*#>EA#&*R[#TOG-&
MB(?N+8J7$#$K,A)/\1&)M8R`&`VP11ADARB&,1.EV+$)F6O"$D8ARZ?2H'C)
M(%X1Z8@Z&5$0^5XET7!8S1&NX]`V[&N[A]ZLY\[YA0B@036,W5X(UD\``8//
M%/<G^IE,;$8>)WUK-^Z.I]O7"3<6_H.Z9TK=8X!L8`>>F]4HK)`KX#)%#7\Y
M/MY?0#SE"*+(>ZN8NVS/PGK!,)OAV4/_QAT*M@HSHS>V2Q1N%AZC8[#R#K11
M]!VYR9&(9Q>&P"]@G:"[GH^MH<\'22+&C]3\'IH`E*+?5N/FV+-W+..+=@Z[
MF[0>>!CHDXM<&!3>)#3RPM%O8;X]]<97I+7$-1H9X&3X_L"0T(B@TH3UIG\Q
M@3_HE(A<FT1$&#;'D^W;/8<.;IE!EY(#<#535DL%@B(F:L8.5=T5-9':Z*`3
MJ!/'2P&#@H(QS*7GC#!:<`(K[*+T#*+HT$UR28VLL26]QV!!6[Z^[GKHS(?=
M&0&!^>]PH+N0T"RXUZ7?!#'%EN^5GTT&T7'T1G1H&3K(I<'%3JP0/#,.GG2F
M&5,KEM$B;^4.99,=M85<0<2[C$TD$\"?\D)1G=!(0QS)]GS%4,F?N.;G8(H8
M@--QS]?B?3F6<SG=SYSS275"IDQKEE\O>W8IWKU;=QQ.-:53/AGCEX!Q:D*2
MBAF.O0$?[-@8JM23,<<J+>"#O7BDAA(Y0$&'S_\R;Z&0=0IP!\0=<DPG2,10
MK44];31&ZF'YQG<^2B+\$<?6&;(I).:?30#8)!"ENHD'$&5D>$B10SN@0P_I
MIZ1K)?:U".K=5/@@&89T#KM:N5[=:)<P?/]P[`5"Z>CH5?AI3P9QG(R!37==
MD7RQHS<J*5]/Z-D>^%K#K\,)W5B(KQM\;.''$1NGOFW+R&_D^A0)=3[!H^GP
MA@0>68&VQ^'\4UO-GEU<%5Z/-%P0Y^*A%]@45[4ZE;SJXFTOM79J=4:;N7L7
MU=-Z1]';)>-A,\6_RUL8<D>AQ0C="^PQ/`*&#E;#ZQHPFN.-5G7^MR&[%R&\
MF^S$R-A"]<CFU`,4#J='QE)?OGS6E]?>C"Q4$;8)C2B.+^F`UP_/P'=\H&F'
ML>-`W*P2-Z:B4W&"!G3G*PL/)%*W3<S;%/--VY"Y&J9N#0>/(T_D<\]>>(*%
M4[BT;^@RG#@&P$`5%&"GOC>8T(DD37D`;5[*DV8=#1D1,"5/6<CYI*_CHA]/
M7/T'Q\=[%"GG;W#@W2IJI-?LKP?``USH8QSW)X?`AD'AZ7^VRI$#TEW*5C10
MV3!T,]J@O?<"Z80D6*7=CR>@U"EM<TS?0IO5Q<C-P6HX6U]<I".VAS$((5$'
MH:@6YUNKR84GIL]CV;Z)%HYYZ:\ZON(-\+)@0::&4W$CIYL$B2X2X$4]NH70
MM_O4!'N@OGB3INA2MNYD?C%'8H$[)4&G.]T?RG"&'LX8_3$^Z;PZGQ8SYR?C
ME*YKX13XJB'/2G^RDX@3(>*$GT55N@D)JPP$P/R`Q@0Q`#0/+`1E-3L52GQG
M:Q3H._O['"J`?@V='HWG!OX[D8$33DXN?T>J`*K,%UH\@0[]6+0S`\^[Q&N,
M@NO(U9GJ630V$7FG%U5^5=94N,)1:OM")EL^"U+,<=-7@Z,I%JD/?TQUC,U-
MJAM%HH2$E+99:_K'(H@X1"!))G*7>"\0T:;Q)A6)I5S>8;UX*U*5IQ3D4!,'
M31/C._P)^MU(#S?`HI$710C\OM<CYS8Z$>C."!YF"+M[C$PDW@F;R'Z>".+Z
M)M7WIW=)$86)FK<V4P\/=I9FILI+MQC%\^SC+N@*+GJGV%7F#4AR)=P/(\\R
MHFIRGSBY&=B[WB`1=\_7M2@^2D9CH9]!Z8W;FMC6'%K7G5HE\ZOC<MBK(P3\
M=,<"$E]0%RR6/&X8`PY;@;PZZ7BT/^IU'+SWY1*YHW'V?.='YN$1>M)/?ASJ
M"Q.^2I<"GNBPHP;3*K%I8!C8$V#N\NH=0V3W;)1E3U!V&JK'4;D>#5,=>%9?
MA*'Y#/_`&3J!NDK4/:U>%7U12[Q2@9XE7:;BNH7W?MXK%9]<V!2>Y:*7L$<R
M/G$9?3098_0PB2OUBE&)KB6X@@_(P`V.%7SI7>*.R:5R*;.H03T)__DAW5]V
MY?4FC_!$]@S?$RW1"_.J[E/SC>TX_6RJ2KZLZ(][Y8`O@9>/]G9VG^\9AT<'
MAWM')]V]8Z(X45%1^_.'G@_&>6==^CR@J7"D&6"E*:@2L#/QS7&C;_%/@-+C
M*/(6<T6'W]$%:F!0HX+R:^%;0=),HR-G$"RV7@93&Q_\79,=#+T^2#%RJT=Z
M7B?ZWK_!_>ZE?^2#88]BH3O17%ED\D"QW\SH#DT=X$3'V;F\D.<K5=%K;HU[
M%V;/0G$>P@K+E_H!6PPQ!61*@[3?L3Z??J0TR/R`5!7OX\(;F3UOX@;QBLK/
MI;6G9'4=R)M(U@!,#K]3@]F?F:YGTLU,V/`U^@\3C:A.)38(FVW`]D'SNXD/
ME/-IX+B7R>\EOIW&P9\]4#.`?22NIX;!_1C<*^+.?(Y/3/6?H7]47T>W;<0@
M\)\]]Z4S]EQT_QM@`!X*Q1WS=A0)BHI2E*(4I2A%*4I1BE*4HA2E*$4I2E&*
K4I2B%*4H12E*48I2E*(4I2A%*4I1BE*4HA2E*$4IRFM<_C]:D!0L`&@!````
`
end