From steven_p_goryl at fanniemae.com Fri Dec 1 08:18:24 2006 From: steven_p_goryl at fanniemae.com (Steven P Goryl) Date: Thu, 30 Nov 2006 16:18:24 -0500 Subject: OpenSSH make errors on OpenStep 4.2 ? Message-ID: <456F4AA0.5000108@fanniemae.com> Good Day to You! THANKS for ALL your work on this project! We appreciate any help you can give! ----We are attempting to install OpenSSH v4.3p2 on OpenStep 4.2 for Intel -----our configure completes but when we run make we get: labnx02:136# make cc -g -O2 -Wall -Wpointer-arith -Wuninitialized -I. -I. -I/usr/local/ssl/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/usr/local/etc\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c moduli.c openbsd-compat/vis.h:85: bad attribute specification, expecting identifier, found `)' openbsd-compat/vis.h:86: bad attribute specification, expecting identifier, found `)' openbsd-compat/vis.h:90: bad attribute specification, expecting identifier, found `)' *** Exit 1 Stop. labnx02:137# -------So the vis.h file is there BUT looks like this on lines 85, 86, 90: /* $OpenBSD: vis.h,v 1.11 2005/08/09 19:38:31 millert Exp $ */ /* $NetBSD: vis.h,v 1.4 1994/10/26 00:56:41 cgd Exp $ */ __attribute__ ((__bounded__(__string__,1,3))); int strvisx(char *, const char *, size_t, int) __attribute__ ((__bounded__(__string__,1,3))); int strunvis(char *, const char *); int unvis(char *, char, int *, int); ssize_t strnunvis(char *, const char *, size_t) __attribute__ ((__bounded__(__string__,1,3))); #endif /* !_VIS_H_ */ #endif /* !HAVE_STRNVIS */ ~ ------We see in the documentation: (we read it all !!) # Don't try gcc -ansi; that turns off useful extensions and # breaks some systems' header files. # AIX -qlanglvl=ansi # Ultrix and OSF/1 -std1 # HP-UX 10.20 and later -Ae # HP-UX older versions -Aa -D_HPUX_SOURCE # SVR4 -Xc -D__EXTENSIONS__ -------We see our version: labnx02:40# cc -v Reading specs from /lib/i386/specs NeXT Software, Inc. version cc-744.13, gcc version 2.7.2.1 ------This is OpenStep 4.2 for Intel and OpenSSH sees this as well: Host: i386-next-openstep4 Compiler: cc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized Preprocessor flags: -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib Libraries: -lcrypto -lz -----Do you have any suggestions on how we may get around this? THANKS for your time and efforts! -- Steven P Goryl 703-833-1292 FNMA Contractor 7th floor # 7340A www.goryl.org From openssh at lakedaemon.net Sat Dec 2 04:35:59 2006 From: openssh at lakedaemon.net (Jason) Date: Fri, 01 Dec 2006 12:35:59 -0500 Subject: mirroring a loop device across an ssh connection Message-ID: <457067FF.8050201@lakedaemon.net> all, I've been looking into a secure way of accessing a remote loopback encrypted partition securely via openssh. The basic idea I have currently is that a file/partition is connected to /dev/loop0 on a remote server, which I have an ssh connection to. I hold the key (for cryptsetup via dm_crypt) on the local client. I'd like to mirror the loop device of the server on the client. Once that is done, I would run cryptsetup with the key on the client and mount as normal. The end application would be for remote secure backup (rsync?) of a second encrypted volume on the client. It is assumed that the remote server is untrusted, hence, not running cryptsetup/dm_crypt on the server. So far, I've looked at Rex/sfs [1], pseudo-tty programming, and a little of unix domain sockets. I'm more familiar with network socket programming, though. My main holdup right now is my lack of familiarity with openssh internals. If someone could point to the right section of the src tree, perhaps with a nudge towards how to do this securely, it would greatly appreciated. tia, Jason. *** PDF download *** [1] - http://pdos.csail.mit.edu/papers/sfs:rextr03/MIT-LCS-TR-884.pdf From openssh at lakedaemon.net Sat Dec 2 05:13:20 2006 From: openssh at lakedaemon.net (Jason) Date: Fri, 01 Dec 2006 13:13:20 -0500 Subject: mirroring a loop device across an ssh connection In-Reply-To: <45706ACE.2070301@noaa.gov> References: <457067FF.8050201@lakedaemon.net> <45706ACE.2070301@noaa.gov> Message-ID: <457070C0.8040808@lakedaemon.net> Jefferson Ogata wrote: > On 2006-12-01 17:35, Jason wrote: >> So far, I've looked at Rex/sfs [1], pseudo-tty programming, and a little >> of unix domain sockets. I'm more familiar with network socket >> programming, though. My main holdup right now is my lack of familiarity >> with openssh internals. If someone could point to the right section of >> the src tree, perhaps with a nudge towards how to do this securely, it >> would greatly appreciated. > > Take a look at drbd. Thanks, I hadn't stumbled across that yet. There is only one small problem with it, which I failed to mention in my initial mail. I can't assume I have root access to the remote machine. I might be able to get an 'sudo losetup ...' approved, but most likely I'll need to mirror the file descriptor of the file container over the ssh connection. Currently, for proof of concept, I have root access on the server, but I may not in the final implementation. > Really, if the crypto of the underlying fs is secure, you shouldn't need > to mirror over ssh; plain rsync (or drbd) mirroring, should be secure. I would prefer to use ssh, as that is the only incoming connection I allow from the internet :) the remote server could be on the other side of the world, depending on my travels. tia, Jason. From Jefferson.Ogata at noaa.gov Sat Dec 2 05:26:42 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Fri, 01 Dec 2006 18:26:42 +0000 Subject: mirroring a loop device across an ssh connection In-Reply-To: <457070C0.8040808@lakedaemon.net> References: <457067FF.8050201@lakedaemon.net> <45706ACE.2070301@noaa.gov> <457070C0.8040808@lakedaemon.net> Message-ID: <457073E2.9070701@noaa.gov> [not sure what's up with reply-to here; looks like my previous reply went only to you] On 2006-12-01 18:13, Jason wrote: > Jefferson Ogata wrote: >> On 2006-12-01 17:35, Jason wrote: >>> So far, I've looked at Rex/sfs [1], pseudo-tty programming, and a little >>> of unix domain sockets. I'm more familiar with network socket >>> programming, though. My main holdup right now is my lack of familiarity >>> with openssh internals. If someone could point to the right section of >>> the src tree, perhaps with a nudge towards how to do this securely, it >>> would greatly appreciated. >> Take a look at drbd. > > Thanks, I hadn't stumbled across that yet. There is only one small > problem with it, which I failed to mention in my initial mail. I can't > assume I have root access to the remote machine. I might be able to get > an 'sudo losetup ...' approved, but most likely I'll need to mirror the > file descriptor of the file container over the ssh connection. > > Currently, for proof of concept, I have root access on the server, but I > may not in the final implementation. In that case, fuse is another option that might help, tho I'm not certain as I haven't used it. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From openssh at lakedaemon.net Sat Dec 2 06:14:50 2006 From: openssh at lakedaemon.net (Jason) Date: Fri, 01 Dec 2006 14:14:50 -0500 Subject: mirroring a loop device across an ssh connection In-Reply-To: <457073E2.9070701@noaa.gov> References: <457067FF.8050201@lakedaemon.net> <45706ACE.2070301@noaa.gov> <457070C0.8040808@lakedaemon.net> <457073E2.9070701@noaa.gov> Message-ID: <45707F2A.8010600@lakedaemon.net> Jefferson Ogata wrote: > [not sure what's up with reply-to here; looks like my previous reply > went only to you] My fault, I think. I recently migrated to thunderbird from mutt, and when I set up all my aliases (eg openssh at lakedaemon.net), I filled in the Reply-To field. Apparently mindrot's list server doesn't rewrite the Reply-To field. I've since fixed it for this alias. > > On 2006-12-01 18:13, Jason wrote: >> Jefferson Ogata wrote: >>> On 2006-12-01 17:35, Jason wrote: >>>> So far, I've looked at Rex/sfs [1], pseudo-tty programming, and a little >>>> of unix domain sockets. I'm more familiar with network socket >>>> programming, though. My main holdup right now is my lack of familiarity >>>> with openssh internals. If someone could point to the right section of >>>> the src tree, perhaps with a nudge towards how to do this securely, it >>>> would greatly appreciated. >>> Take a look at drbd. >> Thanks, I hadn't stumbled across that yet. There is only one small >> problem with it, which I failed to mention in my initial mail. I can't >> assume I have root access to the remote machine. I might be able to get >> an 'sudo losetup ...' approved, but most likely I'll need to mirror the >> file descriptor of the file container over the ssh connection. >> >> Currently, for proof of concept, I have root access on the server, but I >> may not in the final implementation. > > In that case, fuse is another option that might help, tho I'm not > certain as I haven't used it. I just took a quick look at it. While it operates in userspace, it requires the fuse.ko module to be loaded, which would be a root level activity, perhaps even a kernel module compile. I'll take a closer look at it this evening. I'm beginning to think more along the lines of ssh creating a local virtual file and passing all operations on it to the remote file. Unfortunately, since a file isn't a stream (it's fseek'able), this could be difficult. Jason. From martin at oneiros.de Sat Dec 2 05:18:17 2006 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Fri, 1 Dec 2006 19:18:17 +0100 Subject: mirroring a loop device across an ssh connection In-Reply-To: <457070C0.8040808@lakedaemon.net> References: <457067FF.8050201@lakedaemon.net> <45706ACE.2070301@noaa.gov> <457070C0.8040808@lakedaemon.net> Message-ID: <68c491a60612011018l7fd56edfl415ada1e001f72a0@mail.gmail.com> 2006/12/1, Jason : > Thanks, I hadn't stumbled across that yet. There is only one small > problem with it, which I failed to mention in my initial mail. I can't > assume I have root access to the remote machine. I might be able to get > an 'sudo losetup ...' approved, but most likely I'll need to mirror the > file descriptor of the file container over the ssh connection. How about unison? Do you really have to sync a file system? Best Martin From jmknoble at pobox.com Sat Dec 2 12:37:41 2006 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 1 Dec 2006 20:37:41 -0500 Subject: mirroring a loop device across an ssh connection In-Reply-To: <457067FF.8050201@lakedaemon.net> References: <457067FF.8050201@lakedaemon.net> Message-ID: <20061202013741.GE19261@crawfish.ais.com> Circa 2006-12-01 12:35 dixit Jason: : all, : : I've been looking into a secure way of accessing a remote loopback : encrypted partition securely via openssh. : : The basic idea I have currently is that a file/partition is connected to : /dev/loop0 on a remote server, which I have an ssh connection to. I : hold the key (for cryptsetup via dm_crypt) on the local client. I'd : like to mirror the loop device of the server on the client. Once that : is done, I would run cryptsetup with the key on the client and mount as : normal. This sounds like you'll need unix domain sockets. The following may be of help: http://bugzilla.mindrot.org/show_bug.cgi?id=1256 : The end application would be for remote secure backup (rsync?) of a : second encrypted volume on the client. It is assumed that the remote : server is untrusted, hence, not running cryptsetup/dm_crypt on the server. : : So far, I've looked at Rex/sfs [1], pseudo-tty programming, and a little : of unix domain sockets. I'm more familiar with network socket : programming, though. My main holdup right now is my lack of familiarity : with openssh internals. If someone could point to the right section of : the src tree, perhaps with a nudge towards how to do this securely, it : would greatly appreciated. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From r3r2 at yahoo.com Thu Dec 7 10:15:56 2006 From: r3r2 at yahoo.com (Ryan Robertson) Date: Wed, 6 Dec 2006 15:15:56 -0800 (PST) Subject: ssh 4.x using aix 5.3 auditing Message-ID: <20061206231556.70558.qmail@web51902.mail.yahoo.com> Im trying to identify how ssh 4.5 interacts with the audit subsystem within AIX 5.3. i get an event when a user logs in, but not when they exit via ssh. i can get it to work with telnet, however. It would seem to me that if an event is captured from the login, that the same would be true for the logout. I've opened a PMR w/IBM, but not getting very much help. below is an example of my /etc/security/audit/config file: start: binmode = off streammode = on bin: trail = /audit/trail bin1 = /audit/bin1 bin2 = /audit/bin2 binsize = 10240 cmds = /etc/security/audit/bincmds freespace = 65536 stream: cmds = /etc/security/audit/streamcmds classes: default = login init = USER_Login, USER_Logout, USER_Exit, USER_Logout users: root = init,default =========================== below is the output from /audit/stream.out #:/etc/security/audit # tail -f /audit/stream.out event login status time command --------------- -------- ----------- ------------------------ ------------------------------- USER_Login root OK Wed Dec 06 13:39:17 2006 sshd ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com From dtucker at zip.com.au Thu Dec 7 19:27:13 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 07 Dec 2006 19:27:13 +1100 Subject: ssh 4.x using aix 5.3 auditing In-Reply-To: <20061206231556.70558.qmail@web51902.mail.yahoo.com> References: <20061206231556.70558.qmail@web51902.mail.yahoo.com> Message-ID: <4577D061.3010207@zip.com.au> Ryan Robertson wrote: > Im trying to identify how ssh 4.5 interacts with the audit subsystem > within AIX 5.3. i get an event when a user logs in, but not when > they exit via ssh. i can get it to work with telnet, however. It > would seem to me that if an event is captured from the login, that > the same would be true for the logout. I've opened a PMR w/IBM, but > not getting very much help. There's no code in sshd to specifically support the audit interface on AIX, so I suspect that the records you see are generated by the "loginsuccess" call which sshd makes. The API docs[1] make no mention of a corresponding logout function (although now I see that the audit redbook[2] makes mention of one but I can't find any information about it). [1] http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/genprogc/ls_sec_audit_subrs.htm [2] http://www.redbooks.ibm.com/redbooks/pdfs/sg246020.pdf -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From r3r2 at yahoo.com Fri Dec 8 14:11:52 2006 From: r3r2 at yahoo.com (Ryan Robertson) Date: Thu, 7 Dec 2006 19:11:52 -0800 (PST) Subject: ssh 4.x using aix 5.3 auditing Message-ID: <20061208031152.4027.qmail@web51903.mail.yahoo.com> The only way I was able to get any sort of record of a logout was when adding "USER_Exit" to /etc/security/audit/config. I'm still not convinced that that is proper field. Even if it is, then what does USER_Logout do? It may be the "logout" command, which if called from any remote connection, fails since its not "on the login terminal." Of course I get no response from IBM. I did notice an entry for rlogind/telnetd in /etc/security/audit/events. Perhaps there is some API that be used for ssh? Is this something that could be added? -Ryan ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From dtucker at zip.com.au Fri Dec 8 21:24:25 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Dec 2006 21:24:25 +1100 Subject: ssh 4.x using aix 5.3 auditing In-Reply-To: <20061208031152.4027.qmail@web51903.mail.yahoo.com> References: <20061208031152.4027.qmail@web51903.mail.yahoo.com> Message-ID: <45793D59.9070305@zip.com.au> Ryan Robertson wrote: > The only way I was able to get any sort of record of a logout was > when adding "USER_Exit" to /etc/security/audit/config. I'm still not > convinced that that is proper field. Even if it is, then what does > USER_Logout do? No idea. All the pdf I referenced earlier says is: USER/SYSTEM AUDIT EVENT Description logout USER_Logout Calls to the logout subroutine. [and elsewhere] rlogind/telnetd USER_Exit > It may be the "logout" command, which if called from > any remote connection, fails since its not "on the login terminal." That's interesting because it doesn't happen here ("logout" works with and without "UseLogin yes" in sshd_config). > Of course I get no response from IBM. I did notice an entry for > rlogind/telnetd in /etc/security/audit/events. I looked briefly at the AIX audit documentation when we incorporated the Sun BSM audit code to see if it could be supported but could not figure it out at the time. > Perhaps there is some > API that be used for ssh? Is this something that could be added? Maybe, but I'm not sure how. I would guess that you build the appropriate structures and pass them to either auditwrite or auditlog but I've never seen any details on it. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sitkarev at komitex.ru Sun Dec 10 10:17:43 2006 From: sitkarev at komitex.ru (Grigoriy A. Sitkarev) Date: Sat, 09 Dec 2006 23:17:43 +0000 Subject: Local software flow control Message-ID: <457B4417.8020607@komitex.ru> Good day time! Using openssh with a serial attached terminal figures with a problem with flow control when serial terminal has printer connected to it etc. because ssh disables xon/xoff on associated terminal. At present ssh client always disables xon/xoff on associated terminal device, regarding of it's previous state, e.g. ixon and ixoff options were set or not. By searching the google i've found some posts where people complained about sshing somewhere and getting disabled xon/xoff on their devices and thus they had to use rlogin because it handles local flow control correctly for them. An easy and quick/dirty method was to remove IXON & IXOFF flags from sshtty.c:enter_raw_mode(), but it can easily brake transparency. Another standart method to use was a must. According to IETF RFC4254 ssh server can provide client an idea of doing the control flow at the client side. A special SSH_MSG_CHANNEL_REQUEST message with "xon-xoff" string MUST be used, and client MAY ignore this message. This feature is not implemented in OpenSSH, nor in client nor in the server. As we have a great need in using software flow control on the local side with ssh connection to server, i have decided to implement these options in ssh server and client. The patch must be applied to the openssh 4.5p1 release. The patch adds two boolean options in ssh and sshd correspondingly "IgnoreFlowControl" and "UseFlowControl". Defaults don't change the usual behaviour of neither ssh and sshd. When "IgnoreLocalFlow" is set to "no" within ssh client, it handles "xon-xoff" message from sshd and enables or disables local flow control ONLY if it was previously set before ssh was started and associated with terminal device. If no ixon or ixoff option was set on terminal device everything is left as is. When UseLocalFlow is set to "yes" within sshd server, it requests to enable "xon-xoff" after the client's request of pty allocation succeeds. Now we can use printers attached to serial terminals and other devices. In spite of the reason, that patch works well for me, i suppose it might be better but i need developers advice. Best wishes, Grigoriy A. Sitkarev -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.5p1_localflow.patch Type: text/x-patch Size: 6127 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20061209/24d3faab/attachment.bin From noreply at evangelizo.org Mon Dec 11 05:54:17 2006 From: noreply at evangelizo.org (noreply at evangelizo.org) Date: 10 Dec 2006 18:54:17 -0000 Subject: EVANGELIZO Message-ID: <1165776857.20047.blah> The address noreply at evangelizo.org is not read. Please use the contact form on the website to write us. L'adresse noreply at evangelizo.org n'est pas lu. Pour nous ?crire, merci d'utiliser le formulaire de contact accessible sur le site internet. Received: (qmail 17118 invoked by uid 503); 10 Dec 2006 18:44:17 -0000 Received: from unknown (HELO evangelhoquotidiano.org) (201.34.69.233) by ns30330.ovh.net with SMTP; 10 Dec 2006 18:44:17 -0000 From: openssh-unix-dev at mindrot.org To: noreply at evangelhoquotidiano.org Subject: Re: Nossas contas leia! Date: Sun, 10 Dec 2006 16:46:56 -0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_00003EA6.00000591" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0016_00003EA6.00000591 Content-Type: multipart/related; boundary="----=_NextPart_001_0017_00003EA6.00000591" type="multipart/alternative" ------=_NextPart_001_0017_00003EA6.00000591 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0018_00003EA6.00000591" ------=_NextPart_002_0018_00003EA6.00000591 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Nossas contas veja detalhe -------------------------------------------- Te Amo!.pif: Nao Tem Virus! Norton AntiVirus Procura Progressiva Mais detalhes: www.symantec.com ------=_NextPart_002_0018_00003EA6.00000591 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nossas contas veja detalhe

Te Amo!.pif: Nao Tem Virus!
 Norton AntiVirus Procura P= rogressiva
FiqueProtegido www.symantec.com ------=_NextPart_002_0018_00003EA6.00000591-- ------=_NextPart_001_0017_00003EA6.00000591 Content-Type: image/gif; name="symantec.gif" Content-Transfer-Encoding: base64 Content-ID: <000075A1723A$00005B1E$00001393 at 0FFB> R0lGODlhjAAmAPcAAP///////f/+//z///7+/v7+9/385/z63e7tztXSwry8uLW1tb6+vtLS0t/f 3+/v7/j4+Pz8/P7//P7//vz+/P34pvzyZ+XNOJqOLFpPLCwnKiAgIBgYGBISEkNDQ2ppaaWlpdzc 3PLy8v39/fv+/v370/z0i/jkL/3LAMqZDy8yRSsyODgzNDAwMCkpKSQkJBwcHAICAm9ubsXFxf7+ //rrR/XOAv68AGJbRUJHVEdISUZFRT88OTk4OQsLC3R0dNnZ2f35yv3zhPjDCvK2AOeyCY15N01R XFRTVFBPUEBAQDU1NS8uLLGxsf/+/f37xP3xfPXKJvKyAMGdKlthZVpaWz09PY+Pj/79/PjiWvS4 APO6AaiRTGlrdmRoa15eXldXV5GRkf7///zzku63CW5xgmBgYExMTJWVlf7zm/3skfO7BmVlZP78 8v35tvK9Aebm5vnpiPvBAM2uMXt6eurq6omJifS9BvG+BPXAAezEB2NoZFhXXPLAAfTKAZqLR2Rk avr6+vX19fDw8OLi4ujo6OTk5PzxW/zycvndS/TDALCbL4KCgru7u/vxQ/PSHPTHAf/UANqwEDs3 OM3NzampqcrKyp2dna6urpmZmfzxVPvxOPXMC//VCIeCYcHBwezs7J+fn9bW1qKiovnwJfrrOPTX D/bSIvnqd9bX2fjwFvrwDvvtGfXcCv3zyvnvAPruCPr6h/rvA/fwAvjsAvbsAfjpAfb128nH3aem t3Fsb/ntAPjlAffhAfXlCuzaGLioLXNqT1ZZaPfdAPjaAfvoBvbYAfbTAfbVAOS8DPXRALaLEPfa PfTSA+SqB/z21kxKQ/jXVvPDFfKuAB8iJvrvw/jWa/exACEmL/jmr/fGQfK1FeCmFXZ0bpqbp9LP 1P313fHu29/g5/P1+vv7/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjAAmAAAI/wABCBxI UGCAAAIEDBgAgIBDhwMJNCxIsaLFixgzatzIsaNGAgICFDBwAEECBQsYNHDwAEIEjzBjypxJ06KE CRQEABhZwcIFDBk0bODQocMGDx9AhBARkSDEmlCjStVIYQSJAiVMnECRIoOKFSxauHgBo0OMszBk zGDqdKrbt29pDDBQoYaNGylw5NCxg0cPsS82wODg42yHH0AEEhgxEa7jxzBpBBFSYwiRIkaOIEmi Q0mPJUzGDi5aOMaSJoolQl7NmuIEAE6eQLEQRcqNKR+oVNm8w8pf0WU7+Cjd4Yri1sgbw9U5AcsT ISayENGyhUsXL1/AcPa8ZKxgosPPxv/wEeZ4cshP4U4YICaIiTFjam8hw6XMBzO7z3j4HJos+NKG oWHeeW8ttphjEgxwQBpjVKDGGkTMV58MbHyBxBm99dDfaOGJF8MLMxDIWnputVGBCWm4ocZ0b1RX hgwfZMeZb4BxCKB4Z8Ah4mMQKBeVTjS4AcUYKcYR4RtyzEFHFzFqpwONov1343jlFaSajxFBdCWJ 5l3ZkERgZqRaehLVUYUdVlYU5kReEqRTG2MMmUYFcdzxBh556GHdHl/wkUSGNf7n4XgxWJFYY2te 1GZTbVlpIIkPLVrQCBDQEYNxxy0aaZuJAjCBGE9YAAUU78W3RR99+KHHH4Dkl+GGgnr/OFwHIIA5 woERPAAEEHUEIsKvIjwQCAGCADtIHXA4EEEgdYRASI8EBFKIs9AeOIIIhITwwK0ERACBCIZAIK2z gjQUiCFKxGDHr8MCcG0IIfT6KACBDOJAvIF8SdAAEqRxCCKjQpdIH4oUjIIfi7BxRA77gRalcFP6 YBYbD7AZbRNWWLEBrYx4YIUSSDQAwAK9KXEGEx3AEEIYL5z1gSEOMALDWTKIANEDTVTBgWkM3NrI D/s1gMbMMXxQx8gemOWCDkmECEETHqD8AggQHFiIHTuYxQGaPs6FiCMWWIAIwIg8kgckaKMQiSRG ZDBJC/19B/GgEvtgqMWU+PABAA24/wAGEFecVUmPggR+hiVXDKcfI2yYpQMYZ9DxRWFoEhBCFRtc YskZMfQwCAEsx9BBEkhITjkBlFyyRAxsYNIEHARk0kEYhjDQciUCAeEbJpYwwsESAwIgRgmabKLJ IYeEjUgNnPjhvPORdDKHJ0m4AMP1RM0ta1EufKJvIJY2IlAjdIACgBUxXCJQBIy8QAgAQMwcykB2 xMABCAPJYBoAEPwQQ5UN4AAHDCEQUdhvFAPxXwvyBQAkxGB+ArFEDBgxkEvEQAnMWkILjhZBS2Bp AE/YBCkcoYkSHu8QpTCFHzhxikSgIg1PaEMqLlEFF8xKe+KRmABx96VAfCAGIROIIP/yFYYYLBB+ TKCDQCjBARgQZAYx8MAgBtKEGDgxEAv4AQHhd70tUsI05RJIE3zAgXyJgHNVAgAY1IWJS1xhjVYQ QeDw56NEicENqlgFKTaxCUf40RGbYEUrsuCKNoiBPQOpw8+YcJaIdaCJHQjFmEawgMIwgREhGEgh hEMJAFTCBYdiIgeOJpFPFOp9AlmA/QoCCkywIQYbICABJLjBiTShKGZEo0DqYEMkmOEDbPgBIxpR Bw/EwIOdapMbVvGKVbCCFaSI5jNXAYtNxKIECxkAiURBB6JtD5IIbEwgMtEy0yyAMQ2MgRK/sLcl CpCDADClFd4nkSo6USBwsMMZZMD/CKPIUoJMgCcmyJjL/xVQMA0gxAPYAgBRMNKDFuPSHVXxClnI AhYYhYVFZ/GKWcyCFBZwgwQK8gBRgIANLpCVDjc2ijENhBJ0MAsTMulJIzagByGSCBNhYL5SntKW VlziEjYQhmwJ5p9GJCUABlpGAJzRoHzbgA8cQJEGMBITqdmSlmjwBFJU9BVgDatYaVELW7CiBia4 BS5ygQZG6EIXP5BBuhr5SBgIho67VB//KjGzBQhxZkr4Qr50KsCexvOnYgyqCL6gzpeEYAOxbAgt BUpQp3JOQADg5QQpUghjIqFHBEEnQcRwgE3sQqyofQUtaGELXvCiF774BTCCIQxh/+zhAx+QAdDo ygHIMoEB+ipEC/zKP875VSL664D43MW3JlZMIlBUQiEmokonggJ9XBPFYNjSACMa9pYweMlT0/hK H2BVIA4IxQjq5wM6vIR/dKAEHBiBhgVUog5iKMAhbFELWuziv/9lrS1a69pe9GIYxCCGHhImDCqw Ibc/aFldyeIBUaRmEBsIKABC8AIXZJIxDCgUA8VoFlkCoIpMOBQAQjGeQATilS4AwSiMqU7ghvgF IhNIKIZTLkH8sAcMGMUMHJBSH4AhE3RwAZpAQWMr2IERLqgCs+zwgyW8QBQ0AEAafMGLYgz4ywR+ rYF7QQxjGOMYyIhEMowgDDOYgf8NMqhCUXpLFqNFJBCM8AEMkLAEK0CUMXCAQRrrEGHhtAAEEZDB CyS2hE8MQtHCUcIMCLG6QjFgjS+ohBls6IMlNEIEMpBqp703g535QAchCsEZiJMJTTZOPEoEwCBA EAokKCEEYgBACU5gYNf6usBjRrCZj6EMG9ggEnowAh+o8OYPvCBlL+hwOJUTgrYuoFrQdUHFBAKB GXyCEpRgQAhGYIlPNMASDAjXDGYA7k8QUAQgqARTHICJfH3i2+UmRCDWDW4G6KihYWiEaAEwg0yM Ap4DEUUo0KDiCNQBFIVwAGgBgIoxW9zAw8h4mZFxjI7bwHmQQEEygsGHL/yyB0b/GcsZVIyRh4yg CjII3o6Qs2tiZPzmGi+zMTiujGL7AW2KyAMKloGEkrNBCRzosAswi6U0AaARHbBw02e+GjGMoRXG SLDOd44Mnhf7434oWB+QJAkcIKEKZlACDMZSBVRyiSIEaMAGdsAoqrdGABMoQBbQ3HWOd7znPge5 2LewBTkUAQekq4KVX2AF4CIKI4Vo2Xn1ZfcRSYC0zLCBMprRDM1/HexARxXhC+8MHOgACUgYSwum zZE6KGEJ25Z55eEiASyQgATPYAYk/GBssP8cEgVTxNhHTwS8QOP0VoABE0Ix2I1AxAEsn31rak8B CgDgANEo2POAX7A85KFFhCeCwRRsYwSTIX0JlRjsrT7ydumzJgBYkIATRjCXOEgDVWIfPvHFb5uu KKEFHAAGlsBAD+F8DTECA+d+kCEAEoAQEzABNFAArhANLUIdb1CBWkAE4jcNN+AMGUAN1GAFmWA+ NSEpCtgaqtEG1WAN0sB/GzgNUnAN17AMTIANSBAKcJAv63eCPLgRAdAQTmAA2WAN2rANRrgN3JAC RtAN3vANgsAY7deDUgh3JDBS2SQGbQAO4SAO40AOEYEFDpGAU+h+AQEAOw== ------=_NextPart_001_0017_00003EA6.00000591-- ------=_NextPart_000_0016_00003EA6.00000591 Content-Type: application/octet-stream; name="Te Amo!.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Te Amo!.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hRXNzYSBQb3JyYSBuYW8gUm9kYSBlbSBET1MgQ0FS QUxITyhSUykuDQ0KJAAAAAAAAABQRQAATAEGAAAAAAAAAAAAAAAAAOAADwILAQAAAFQAAAA8 AAAAAAAAAJACAAAQAAAAgAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAADAAgAABAAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAGSWAgA8AAAAABACAPAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAABU AAAAAAAAAGAAAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAEAAAMAAEAAAAAAAAAAQAAAAcAAA AAAAAAAEAAAAAAAAAAAAAAAAAABAAADAACoAAAAAAAAAkAEAAIAAAAAAAAAABAAAAAAAAAAA AAAAAAAAQAAAwAAAAAAAAAAAABAAAAAQAgAAAgAAAAQAAAAAAAAAAAAAAAABAEAAAMAAAAAA AAAAAABwAAAAIAIAAGIAAAAGAAAAAAAAAAAAAAAAAABAAADAU1VSSVZFTEEAMAAAAJACAAAK AAAAaAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACA AAAAAAAAAAAAAAAAAAABAAcEAABQAAAAxJYCACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AACgAACAeAAAgAAAAAAAAAAAAAAAAAAAAQAHBAAAkAAAALCWAgAUAAAAAAAAAAAAAAABADAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6fUAAAANCsTExMTExMTExMTExMTExMTExMTExMTE xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTE xMQNCiBWeEJyYXNpbCAxMS8xMS8yMDA2IEVzdGFtb3MgVml2b3MhISEgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCsTExMTExMTExMTExMTExMTExMTExMTE xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTE xMQNCmDoAQAAAOiDxAToAQAAAOldge3VIkAA6AYCAADo6wjrAs0g/yQkmma+R0boAQAAAJpZ jZUnI0AA6AEAAABpWGa/TUrowQEAAI1S+egBAAAA6FtozP/imv/kaf+lRSVAAOnouf///+sC zSCLxOsCzSCBABYAAAAPhaYBAABp6AAAAABYmYDKFY0EAlDocgEAAGY9hvN0A+mNlcsjQADo ZwEAAOgBAAAAaYPEBI29yiVAALkpXAAAurzjcjqKBzLG0sACwQLF9tgCwgLG0sgqwSrF9tAq wirG0sDSyDLB9tAyxTLC08KIB0dJddDoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVRSVA AOj5AAAA6AEAAADHg8QEu3OUAABqBGgAMAAAU2oA/5VJJUAA6AEAAADog8QEaABAAABTUOgB AAAA6YPEBFCNlcolQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKToaAAAAHP4 K8noXwAAAHMaK8DoVgAAAHMgQbAQ6EwAAAASwHP3dTyq69boSgAAAEniEOhAAAAA6yis0eh0 SxPJ6xyRSMHgCKzoKgAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuTAtJ1BYoW RhLSwyvJQeju////E8no5////3Lywyt8JCiJfCQcYcPrAWlYWP/gWVJVjYW9I0AAUCvAZP8w ZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAAcSMCAAAAAAAAAAAAiSMCAHEjAgBpIwIAAAAA AAAAAACWIwIAaSMCAAAAAAAAAAAAAAAAAAAAAAAAAAAA7CMCAAAAAAChIwIAsiMCAMEjAgDP IwIA3iMCAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NBZGRyZXNzAAAA TG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFsRnJl ZQAAAE1lc3NhZ2VCb3hBAAAAAACo4Hn72Me4V0tUeb0tc8Mglz4uCfocFNLvPJXcqyraDXwc Eu1YY05YXpaH2vyJ2CI+dt8bFE00VAFZH6E5m1koGeK/2z2tM3ITMBcI0D1+nZ6MgPKMonrI 8Km9PV1YTl9RqoaVjqfXx1P5PRTk0Z7KQqHHzDFSOUWUHV6fsI2bgH3dnxXcIiB33NlJPdiR gZw2yY7hDEoxxsWPfWaYlf/FhVo/bkbcT7RB2PFFrKnHgyv4yvjBdYRXQS42vvj0jXS0wxyC qlFmboIN3EGEn6K2dcxmpqBvclmBYgSJKqf6QCI5H89WK0vJeKcbkgN0ar5dLDfjcWkaQDa8 KDQO+ddUsK0vdl52sK7zR4HiFftfKcJjzoaQrntTtBidKl/sZQ3DoS/H14hxEHpxs4oms8j9 dQ8p/Whg8GyEFmph8nDrY2V+hGsn7PYvswC4MT+og0cjQvGoTwSah0jHUXgqD+0PPU9jKab3 +sNuuS2aSiMkRCZlrUltsTyjFfblgwfKiq0ueLpqB9rviQwFPZVK1HKY8A1OFfMn8V+B0FlH imxD76barJ39I/LK0R4hoyMq2MOZv30emwzNp/JQhuC7COv2rHPWv0Q2qEjwgw71xVk9ZvYZ xByz9FFq4eVDLvvTg2Aem4cCN1gkTPfozs9X3v/8/Q1Vk2Gy81UZuewjWV21xmepshoOzvtR SwbOH8XF6ymfbHk1uBYfpnZfgfve7Rvzh2UpYMeO5WIaZ0trhFvO8xb8cYM4y5Lkl4T1PLSI 1Znh6+7mtnU+s3WXYj16Wc71KniHwGYUglIUSCDQauWg3Ys2dMJCLZJEmRphZsZAdOOzXGmf mGbtpWX+sjEFEiAdX3qSIO3h1aPPMCcPY8BOlNfNe0dBtdOGJFLtB79xxSUmih7zh9K5PeBm +9tNSDgrFOxB3Y/SNQuYlIpKuLLFtfEgaU8ZnrpgfEYOtFsK+3L/Hbsdfwx1LjgRTkhnvFAF d4d5LNUd70dFLxPnkT/GCo19YIiGu9Sz6zkvAPfIEgCdWPp4PCgIWCTdYXscSqrhPl0V2UOp oH4JKyzsAyCk0oQKWdLC8ICUKSmymoVaET2skWUIYs7qoUUtxw4uqsht/urdZiaH0r9uZ7V0 lbqzx0ZNc9buUc0KDetFdzQlro6/Icf4ojZ+5gTS1TTdv/ZLsGMsabwBy0P0RJCANHI0S9Vh Pan/++U0tpTesRK0YxCwGc3Nhiz25cpmlUM4J6NSRbysswDU29XgAUaYuzPPaEFZeQp7isbA q7gioib8H6R3gEWI4oa9GLPB1+K4JuVCi/rfGjcYnTPQXK5IJXmt/mbEvmWnJS3ooge2K2Sa oqysEG4+H6fw74NtB/6OsIMreX+3uXpi+wtNWDU+5ytOt87zOGbAr/zm5dRUed8FTxJG7gyr KAKJ9tWWOZnDuM+RpKswL01vjXQORvJcRPiVX1wXo1np7ibGG30mgyAEHSWZLw39ogmh+GjT mfNIa/Ds/drLIoI9oNBYj3b3wBC7YDACyqyhUZtHmbthSg7EqzrrmrqozFYNSiWem9W4h7wI H1Mvbx0yJRJiR136zqJUNfhku5m7GT4M9g16R8abDwpxzMvkqVx+nxOQDmADbBp8mQU9FShQ 91NfWoI/FGE/vuoFNlx/Rx4gA1FOmFRb4t3RWNkYJ49yh65cZwD9EMUALYzRb4rlR343SPwW lZbxXWb5AFcQeAE9FQb2k3JTen+reU1aK0kqt25pCy7FqfPTzfJuK2ynx3LNC7Q4XqORX6Of pNRKBaJOdMi8bXd7JcpzOnHyekkRYOW8sWc4Y66hpj27Ss+lPg3JFhpfQ/h3+040vQKbiEyM +CFk+n2W8tGmA0q+CPjcXBNouwELHnrGCS7i11YmK8HMnGaXkAMVCWvvj7ifwEhcevL3gtpA nHZllwBiMwBe1oOneupwoDOaNVett7kOtBKrr3fHXrM3pxxwAkLGKW+gguGQorV9/qgb66nw y8Y7+UXGLqzY0sAw0t/70wTFt1TgrOekVbtFz8aMx7ywgext41wbcpK2iB439mUPf5B2LPR9 bCqZ9nD16AayLUiVLwOaMBiUjUcoBv12PfvPKDBg7pfo8FAT97ULhBetWH0NlB5vDpx8jNrp ahGwGjfmIgF1y3zHqRzGNiHYKQkWEysb9l8Sb648Pk0m4g5e5F41Din19PmlzXjOeUyHKV91 X3Og6tWWcG8HCmm24AJyxz0IXxOrDUzA2Uc6EC2sz4R6J5Q8UJgcKtS5ljCpdQc86vbX4HZm WeX9hO5f1syA2OyV+1f7N5fhzwb+G5kkYamq4fBNMCZVB/w3HAI6Nst783hQJ/dsVulmToQR xVsk317FCsUhU1LUtz1hQAXOQN4buxMPJ+MsR9Zb9sZjIIt55Zxq4YodjfXHcH1hobwR2kls 721GJ2jOcewc+MbfBgxaTJVe6ywgrZ3W1f+ZNYB7MtLOoPtqkq68gepIkVN9aUBCyf6h4WoO gMxrCqxAlLusWtngcWnjoV+sJfmDt5iMm6Cnz29PJp2JZ7fIW0RO4/JpnukVSWnYngdZKMiU EwQzeJvegS6MT8tbgUuGFHZgFtAbfozpblsP1MU+UkbvQIehWAsjM54SVx3e4F+I6YJ3ki0x 7Sl6DQdFSRbEV0iDWvXEu15s2Z+aC/sZXD7mdFcf3fH1bo4iTMzFLTa8AxYCUN/MP4IAAGT7 zH9TVLv8ZK5X/j3UkGi4KG7AxfKdBBUe9j8kPPXIX67twjK51bpN+SNUiXrhrjFBoTCJTLIw 1O2p0vk+ZKcuxy6Jwr5tDS96W2ySFwqhYm/mg0xvaVMzXxzvpU1/HWly8ONQ9+j4Sa22mV7E YZoAtCVkckHj4KeQKPDrYSQU/7aO/zTOH6s6sYI2c8K1tAkGE3IHLO5ek/v0+A/B6IZeA0+a 3iKSjfhd5tk6qxaUWtyJrNQyHxBcCPnWkcYuMvFhYYbT7Wf357RW3izzMEDTQN2zxMRiQEa8 v7zOghkHkcK+ENWmpfvuDX/2zkS/3AK9ML0Kb6EpBnYuyOpVQfdVLZsX/q36EhZAX4pwyJRZ bOoKfvPP/7NlhZvnfQ11HfnejVHVURooEu85Tnj1NvVvO4w+1IfDwje6qcdDUdKWudAJwxxT 7B0l1EpxaWZtKamJ645Ubpi34EWUSq3xhb87vvrkMc8SvDsx43Uo74tqlLQLiwE6LjeE27zj sweaEw/WkgmWmEVeHp+IHB3W4tRutHLcu2eW57mgLfNxeQvfUVBCIRYEG4HNvNw3UrE4hBc2 uiwZcBz2JYo7Ef17TyinlWDy3TaJgYJUQ3k7OSD7K9v97plGxx8i20mM7CRtvLHSLOahTlQW dAAo9RhXRfGDrY49sEPH6/VSoR4wLBr6uLeM+3KvQZjjKraqHDpIUmjXR26uD9KKGfXmM2Gp j0DnIGXM3crscYK+pfoxfz3PXicsMYoZ60o0eYyq9kZNVFuJG1TWhnisqy09yQTg8UxQFizy U73ZHQyYhvOta0LWOYmh4NARridYX0hN5nDsxpv6W3UXmYtIaiD7atIOawkG5ZoOIEJM5loS BK+Eac18Gox5GhK2JJkooyiD3KHXpLOA7crDxX0U/8a7gTVa5apo32LwzaHA49ITZJ2c0HW/ j1UzQQkqKBjhhHcngab/AL95XB5mYjtuv4+ztEet4G488toa/rzpWQ8ictfnyrY5kXYZW5wS mclrquvgKiDktxI7bDvMH+Mvq/86jThJj6f/2H4bX2cMXjJ5e8rWuGeSBzpNU2l+IDc5I+QP 9o3wcU41PWcwojsIW3mp95gD4h/ZUOyczpdAgj24xnIYdmewaO92jX9sf7FtArLMxw5F4NOy PnUQdYu0bzY8uvswPOriWHm8Enz92r7IFdztwxs/kkNgC9eqO1Fh6M4WIJKt5N+TB/uVpvuA 3ERVOvV7syPiQWTHl4qYqq4SI84gUMcurVP1p20z3lvJreX03GXSdhmYnkJbuhUGG5AulacU lfXcDd/U9ge4uhv5OjJtIQUkJiolYjTHsev8JRY9NURzWIMe9bbqGBaAgecbsjtv0G9iTZ5o kWO/Wl3OqGvL2S60iy5eE6lqj3Hwv6yk5BKBa2DVs3sV7IKyinWWf2Wbh62+5obrAoo3dS54 fX3xJPOkNbUc/Vh9saQY+X1Nh/3svkU1vyGGcL4xkklyZXxIGaY7+qR2G62JTRDki3fCQxh5 /9VGoc94INbFiaof4cMGKvXnp856jhXOf1e84sjPCx0buCvnlLqHIkU5a5dQ4+XDrMuAj2R3 4f9gAPL1Qr8a9qJITmJNiiYudXVyihvWYOsmJxXULFCaTX3tqCEGYp5HIBELsvQ1iwU+TDbr W9TDMTS3z+hXVRe5FdKLP2iK/7oK2wavDYhRWCnx0qQUSVM0+WYMJFvZNRfMLmhu91H7c2TY SJsxoQUivpzn/Xq72Y8e63jGxIJ7OWxQH1xoeHbWzlHe2kJYJy7crcKN0ndWGw261d/n+EU1 duFylG72hIHS4ons6yoeKbwZjBDfFsLFQouN02zOutNXCG/J3KFsfhyqkw48WQycqR9rlHH1 DX3lAX2Gp6PDkK6SQftQnGSF4X2CPTwag1+zI0KutulMEDNN1kcwp1rCIGIh2mzT7ZT8c2SX C1+G//wsEJWWqdCSFlOYwVB/tCA3rzsOuI+idxbdC1CMkmimVl8Q0XxSII1w/hTVz+9/d8Ly uvgvrJqdsaUqiTMgIAGg8lx5hDkRFaYntRryVQQRI5sldD3N3AXI8w0iKYXo1iuNqR+GBMiR KghLBUrLa9b5KrRZ0b/4Vj8bYiL92MjwJDTCLpy+8IQDhVc0GWKyR7IcjshZV5oqTVvhKfpY KxKIMPrh4WxDIAaYphbFDQUTRRJ3P45rTFyc6xQ1usJBPlRUqAciz7KrkJ+MAPhzAVdKEpPl c9Mcs9bNG69+zaQw4Gebk8fEbORLXc3HDSg1Ch2IK96bnFh6X8NYb2Xl0+gNkutszl0TICNV g0iLpwFUKtp3MHJwBtXAukY34tXUTDzsYlEnAvinaYBxPpO3NBo9t3Vbc8hoJ74cHd3nwtGF 3/OW4+mQ5Jky+GHj+H8jEJfRovhBoPl3vRWqC0Z+LCNzCAwUkn6NSClk9eMZsrzhkCa8V4hW 9iJUM1dzszbR1Y+M6N61eVtJNLwCUJGHNN/+h1vH5y4UTT6rJ/PlB5ychgACUL8hEb6RysLI CnZiIvGz+pxkXLFBXio+BuvybEsb4iWOKBsCCRQZzTUIVuqKFvZFXi/lixEj+8ygsHWOmPmE 2ma13K6wuUe7QUejBeY459AaUolIySgvtUAucfAh5mWYQD13oVyGeQLDUAIGBOCVhly+LQwV km7o5QdHuUpaourJwGb/qKP1J/fOr0wxK3wJjruzj7l7Mb/d6VO+aYMfLbO4PAKBvw1Icgwj VwF2MG/Wor6v3yxQH6ano1EUDYC5tRwxwyrbHxiCxbp0Rrbx6JG34tpVXqRnpIFnJKMXQTyq llzD4Gv8M+DZzW5CzKxCSNnS8VoLR827nWA9BFoPXA+yYiJUEzBieDkT0wNwW3ICtVZngox4 +50QOdQpJhXd6PJgVQmJQp0BfGDliJ7s4yUlsfAfgf8SpC85ZxQa7lJTVTrhlNEAVMjPm5fP N3ZOm6E/bnh3HfHrSyG1HlxbLDRShE1AkxfDqCUxyxKMGKGS6rCax2NOlkXYp7NKkpHM1IXy JirJOXdvf1XCewZBuoLM/H8h7pNhqPQMvyJ2ZoQHErsZQKzy349aoNBjGET0SB2am80Pj56r rpvprw51XBDyjrwFDUEka6WS507OYOFcRn5e8qtCiJZRW6Peg1vuBTaKPtYq09Tmbv60eowB yRFAB7NbjIAf0dwgg6AXCR56+p5GsGO+lJEEB/i2YpMzZMGQDgKNpyqgOQwixn3H9jQGMP6W 7cHwfylKfT7qOAQ/Hocd1d3z3ARqU8zsab83e6IJBl7MK4GvRLN0GcfKb+hsSIat/Tk1VdLs 6627rvHx8eFZQAeqPqjuiVzqIxtIOedfwyvYUeCxIDDa4pE8Hat/IjK0aJrG6mmf9RnwixMD fC3e+J3JNgNOgryNuBos85EkSr/HneLf9BypPdrq1eBru+knnHvO4Wp31qMgN22Av5GrBNK8 dwfzi3mpfj4z1wwetnvl2cu1pltigp+OWSLIGlxPgEtfK+dhUP/QpstVCuqeQJny1KR/oe4i EiKZubhEQj1ZUalPhKh4dyuBQo7E9aJWMoztcY3r+TDyS+bd5dSbIa14xDQXXdC1AdrmPkFK 9TqdB9uagrcJaBtOTGWs0r7qX7MgVlME8+jN8F/UVX2eI7EhyCYwq5znJa0VYumqw8gEV7XZ ObphtVCWpqC9OEaX2NInSRIsgMQb9m+vozXrnp4Y75rbmxcgJqyhP/9KqJkuuKXSXRrW8voc DdmK51kFyBQlHZa93vQpRsZbC/BaA60DeKKMz86wi7xDpMGoNkmsYQUYQ5qAoX1CLfHQxa62 E3QrABY2Kpgp6mnwlWfX2rhbEGGGR6hO/LxEBrf8jAW2jpUjXbfH/dqwCSmah9vqVTOnIYCP iwwsPD/JK5Hr0VECIGpoU9/Ck0EYXO9xl7JBY7QheBvOx56J96dNb0+JGUjyWvyEjg6aQ9iv gIKHGLmufZ9Ggt0+qraepxUJNEzqg9cg4ZRmwPvVrK8McmaGq233+UWrP3B1AKhGTbGl2Dth RFksXkI42LrAG8T6GtkoLF4p/EGvPCVOAv68zEIpsTKnDPX1FEeh7eNfAijgk6QSPNNhx/e9 qrezpvlHM1tXGFSR9vNTuJS6VVbsyh8dHGgcIdRj1GeySX/QNrSX5DmhYozWIVPkpp4NB8pQ Uzq+1Q3wvm7sJOUrf/vRw8QzxjPrYIE3lseQBF7xv+q5dI6C8ZMosR3KIWiYvy1iH1J7zecS HfNdq/djdcqBcN3PgqyDMXzPB+5fw1Q8EM5VnQx2x/WbsOo7EyJeWQcIuRa8W019qbh+z0+b wH/YNVI4GIVQambm9ywKkipN1ydL582hq6b2uRWinjb+cfCMCAsV9UQ5wtBCHYEb8h+iKLtC F6rB4jIDZCHUDDJ1TzIR/MGbprskw3uL/I5e9ApO+lmIveyMRgrBLXb5RWYGCx5jFIsnRxwa bIAfIpntMYOUPSvbVRgZuaCEwEyc/kPRdhagWGx0lYiPNxx+01+1gIQgts0Gagua2fJVKNcE xfNfNrbwT+lzSELoMeOKTj4Mi43NzCZ4NSCXPMNmxbXN+XDZaM5kHnCdpRKXeavhPPfwxmsD JSyMyBHGzXKVNLncJjAyyJc1gemt+Ur1t3SUvVIqIgvnKH6x8NqR/BgTlUFlmn3et4hvtMWe QSrK7hanGeiP4hVXJ7zCFTGSEXgHC121QWQaTmEsxA/ypqdyyUqy2qPQZX/8RqEesS0/IKtF xaN5JDSCzW7/nhGeqhhYPHohlHoeYjpH0yClsPn4s+6kPdsuSmnDWn8qxROygjj59BaY3Mjg sHzfhuIiG6ta7rOMKUJneHIsOBMZakJ/MB3W4IBpxd1KqkJEZlnVsiW6p0vHGhzVwwdUvdTM a4HgH+qiuiWlajSnaxrUIt8G5GEULMFw3M8t2NLOyQaxwu3n2PmVuHNuI6ItAq8j9ELJOJi/ s9fF+GK0O5AtAi0xkhl7M89hDYdx8+b6CS9F/EAGH00zx4OlD9GW4P7m0D2bl04NfFyC6BOR +cec/T8UgXpBWUNl+WyZOMprdOlpgOXTwGLTPQHZr4kL7RogM1U4mR/2veteomZ7NGO3kpyX 7hQtznxY1aI29Vg07vxTZC43GW/ZZ5XeKLYQcwdQBSC7opzU3PP3RSpetHpYPI+Gow2aFV7+ B1N131jJjVbQuPQogAH+rwb27M4Y2yYTEn0oktb8LZlTbMwLxikiLVd8+nESAjJ/2M5IRsbg kIj73O7YnKIvXd9ti+nyxvju8B/76zLLG8QvZ09vFUbD1pjREr5D/titOT4IFhaaGOyy9Cbi bMDV6viCY/6g+ypJf66SDVtq0H2RDyr0zGBcVCWfmqlkSiKwXhndu66Yq53ihkkehntqY+dO BPsK7RX2fm/hZLHBrbAw7AS15238a24CYkojlpTaC2Cj2MGesSDIEr+tYqK8rtVBOJv7yeVC uJrlt6ixY9v1e2OGw4lDTPwSK/bdK7SFCUH/tGomGMtiQiIJrROmUU/RJl0ZcZ1ZFJP8wEgy 4NjqcCidgltFyRcZPP49yss6e9l7EcZH5BmIDyT5wM9jQ7an6d+IU/j1XBkZe1DQdjLong07 kcXoSbQV9myN8c44wn9QqhCCCjdz4ZZmUMI0WPxvXRZyuQP3WnieQrDo2wkqs/4dkMVztTIb GhpvTtXckr1BYT7+/cqkWkZKritkTt9NLZEIPsRDjzpljP7e9OMYXrgMbjIglBbUb//MtcPy zVL74fuIUzFWvVuDX5EGD/lbK8LMmF/FSFAzZxpCUCpktBElVVKWf9dUuqP4WBaOTrPe9VOc ZFWZTNSBSI6lJMtRtJUyIGd2EPv5/T+tQGPvkMxZIvebSGWxbAB+w2AUo88Mqaza51YxnTgu xijnNxbdJvyCilzqh4UdVH//k/4gZe9hs7WjQ7AIxjTz52UtlUc1F3SYQq2OLPbELqX/G6Kf 7kKHmNw9vexMcQXP8TPUSvdy+jLkGAv4XVijMwIu9LAMHI3+vqhXRp6c8MhlxJJMKsLagFKr zjgDak4klIszy6V1Uma+J16BThJ2Jam/JWEcIiSaz4jZHiQ9uzk+ETHoZD0p+fDo7UDe2g7u GzkguyDX1stcRE5XSPMp+dskblh/5055A648vNm0IF0Ipz+vGUYjto6YCPbt1JL36JxoNt7L JFESmdBkiZk1uat5n+LrJ7iuynsxWz3aLN7lR4WCapsKPIHrOpOEXWMsoqVOSg4+AzFiQ5n5 vLxTjJBXq4U/EI+tvzm2qLhJ6UGHPKW3sATvErYv3nEbRS1XN1ILRx04SiLr1upjq5ubKaWQ fIKqTVRu9BDxhtPXmiBZfvFnJWRJpIRSnc/pk17OoRxbB5Kp4NQInT42P2am28oG9msUhYnH e6I5l9nCjD6C4cin73g1f4ue6lXRdVw/kt5dXHt8l3MKIfMasMVSQLr+43kOcbYXsk2FLkxB DFj/lr2gNsy7+nty/eBT29NbJyvf6HtQgkXPjESC09jRBInGcInrqdbxpnf4Cqag79y38vDG 2nQghzvpm1uoqYKjGlIZE4FDdbggblZCMa463V7XAAEmzPHNI5jBbA3NYDAnHtfvUR6Iap+k KKc7k3V2PQD/9tWQZxprubiyHsc0Niu0yhE3BoZInaMz14QSNucuFpLn+OTwziMotbyE79qP 3Nust+rhbZuUtiAmS+nvrOHQ8zg/59yLNrkn7I5G31iuG0QkAjl/2BMV1xXwuRGCKw38VmuZ Gi9zU2EnYEdsjDo9dua0MMxIN9T9kTrhTcK27PprL9hN5HqSuRLal2y7TO73C4ZsuxQGRbDR JLeyX1Xq1LF833O/lRBzCcKKbZlnkVvmaj13q2pOLPI5YAwv17f3xyq+0JIRKULsIcEuAsHg QfJmadM7JaeqCXN0TH6oJfrDyqfyl+2E0oE8ubncdpOfy01vjbLBPHqP1tgntqzv5Xfiq61I ev2/XKJ7/A9Qa3B58KG40hYEo00AN5WSXpLqcPmxk78I4i5d05sIlwbob2U6KbTXLmfJGxmJ Z5QeYq59nL0VwD+DcmNBjjAG83Wz1XKdN3ccjqgdR79CxaqVq7MjzPvCFZSd4w253811FzQc FIeu6VNRlWItKgBcxn3SY3T7mphBzTMewP9K4gNiVkHFod9mR3NrAth4eFgewbkxcjk316zC ahqhZ9ACKrtBVYYt1iKIAVxqHMKhLOQuWXZhreIqJmqSOoItfLIMCmRN4OprbMc5gQfiau2z kobnkBKpNQeP4Renai19/ZqBpifmyCRvPGQCps/PRi/Na1AZ7HM5Zz/w0dm3X4J4Wuv7wJRp zCji19ZvJUQVaUOr/ailaapl50rQlTX14cVMZF2DUhHk/IIeycMmRgeHcjlwj33WVc8rB8t8 EOB2oCntWxlQdJ4/OfjA6aQD7uPpZYN+1MAIXOFBslqqIRzcPcOJT/fQn3Qpm652MjkBAl49 j4dY7/UVRJ/MhVy54TVi72Ef0Uo/EkPuvAbE9kFCEyCpLrI5t9OF+EDHzHlcJmST7sxAQ3V7 /Tg1oPrgWtRazcAIYw98/EwAhuLdqZDTZJhc3zj4PVwZZSkZKLTfn1zD5mO14EQPYIvAqWZI 0UHuyyqsS4vdAfqoQSbKHHikRI0jK5qlumGYNz1YFmhBEw/h8tLFNv6JliakkD9yP9Fg7atM RCFMjM3L2Ta/JpQp+tv01Qb3r9RuTtnbOSLfdgE/cXtOhJn1vQFIfS3VHS89LB1aSZEoTQn4 fBHt8K8xYEbRGOqpQicTdEjTn+INt2UjfmT/KGtPMFDbz2UWvFBt2DUuevooOtEx7RMPZ0xv qM4Fv1+qUx2SjFrp5oUNRNDhgw1nf3Rl0EwjYpp0NuX1iyDdCeFnfp6I26eeA5FrNZ7iGfnF izTGd1fUjt3nhewx3Yo84JV2q+yKBVkBJsevHzcOggy0nC2e8dNcgoUdYCTbS6usWpmu8Elx /3s5Zc478nTsDcZg6zXxqE5FkOJKplcEOBti8s4iY/bMWQ/zunyQNLYLuc1rBdGTxebbRAC7 usGoHgCjU2MXIrE6zVBTliiZlijW+5B3PTIM6xCRzsN/JQ5P0MgRVtxbyDMdFVv/xQT8QeE8 Sd4nZQrMIHbR47pnyPiN2loa9LAW5atth7AFwCk05MqO+D3L2EJ4Eg6wM6IDKANRrCra9PUm k/Iecum2A/AjgbqV1TOObn1l2k9rYaKB9Z96zHDq/wsrtkHQ/wwEdCHvEKKmDn4xbY8B/LKm aPjlpO4y8S6ZIYMtvViCd9awyTQ5OeRAmae2LcfuLsyBTsw/4BzOLJ1ke4Sskk7MA7u9DwCg nfTmGrAtORQo5RGcLlnMoIG7PaUGVfselRN5StDt6tNsM34DujvvCOzSi+o5BTCM5avbe5uR Y6BSOtoKzXkW7fcVUS3uoJqT7IW4mER/mm9LrjNGCAgGTRieMaL4EGwVi1lmk+ChO19qDSz+ NjSOlCB1Lire95h9zPB2PQbw8ju4Z70Tag5ZNLoiP+gvAWc9ywEzLUjOY8QXgDome/z8TyYS Fcx2AYeGxThJDt0cFjfJMlFH1sEvYcN7r3MQGO1e0rYrRA2qZQCQr//opyxE5J3Wn5ePQvgN AoGAmeEtMuf23OQaIYcY/SMMhhcNhrDBMCpDF4FUaW40DAQYT3O4R27WejCEwrdbzGA9CoTH 4R5DclANguBKJvZZxNcNFBv1q9F3RofgBlmE5tfdevEb5czzlmTg2t9UI5S7dxef8oMBakSh FjFyuzcesHH3HLRDaKqBxnrnQ/E/FcqtqCQtUnF07PaOjZQzzrlZ+wf042O8VB67gXGNcXRA v5585BdlD9opsz3sumjmlkTTAsOnFvOD9hOkeADc3QObb39g38lVRRQY5a2BXwqY+T9KIflJ +rs9S3tCEY3as/3rcwDOfkZWLiMzRocQ8KylbyOAn6HJROfJ4kOGAjeLP+ua5lmQ2DGb3GLQ A3AtEfN3OVZh1Fr6K5kr3ydVJm4PmmHPK8NOEmRrqmvvrHMdEepe4gYKSvGIb3px8XmZAdJE 2Q83OjIWANvvd0LWAV8uOjlmh53W+ZxvvvqMqLNGj6BAzfhulgvEQxa3spT/rJE2jdtTcfPm Eb7yuwVZ5PA+dmuHgPR9IUE6OnofpKN0u/EFWyafnqrQlvMwJZ6eL+uw78yyC/MZpIR4Mld0 Cgq2MCpT4avlBnH8vsd13iRld2s/0ZXtkLYnUEoyGAedUwXPvCz0zKkfUQeoOWSg0QX1PKCA dySyri08ZzVQTBQolQjoFx0m0dcTDx7rQgJsJYteg0xFV0RrnYlX71uHqHAhz4vLg8i8w9nw BQXWsD6SJb+uJ6kVhFXZ+8Uz2R6wCww5oh7VzZGlJdoZcpgKyxQGSVMvjneYv9Y8gKHyUGD4 1aLcTpOtcIWByV4Bm8WDgkCxdgsaiRMzRTkbRCtgOCA5wfXSvBORH3zlwOVIJi2TAmgVq7Xm LqSCHIx+QmpX+QWhuvxPv5Dp6kpVXqBZYZRZCiUt/8mj/8s4iy+N3F3l1p9XdyUXLAMQ4um7 KtDayQKNdUR/8+p0YETKxqrGjqX/3RyCbLL+8VqkppbM+5Wzc3UTr2ilfKBsnp4BdhPxjfn3 R0ljkqwhg2tTlRfOUA59CrQpEadJNdVgExFVkWpm0ZgT9M7+nAU6Z7Og5N5s/oy8dEIo+UvF NtDF9RYeDTDH+JpIjS4rIBUSAvUR5F86/qGAon8/Y4WlUO0NNGiveTUWPWOxmWf9miOwP7R0 swKvI3auBdbZadh38fQZ11ZIH94LmkVOP3oIWp+XGpsHxYmUoB0w79ddUeJm6z8RiWxsx6EE QuRKE2+mHT/tmACCsWcc5zK8z5fYf7bwWcONaZKazmQi3UGSGQVAL4f9XeVpkAj9GlseH9qq 1lxniluuzfchgLdWhQbGJ8pW1xGD8Egg76oKIl95IsxqQyBv295d9zsND3kRfwiZ9zgnC/1d XF0DoGRjU0/hpsWwaP6pU841Kq7vygXTudiG+8bkrEYApESWwzizbVKN157tXskrIHPPw6NX mgfXMkPAh/6b/tPBmgA9oRqZjkHJ+Z5dDe2tbD5taJHWDekb2/tSX8JyIqMLZiPHjHBz9m5w +1RGBZl2a7y+eoPt1IvgjUQoN8s2241XM/ttndB8XDPFJIo3TfG0K6F9Kpgx5LDEQEcxbI/t pYrQ60mY7M61OfdoNhrc0SWHMNVBLflz7l0QNmqwMcxz5bOeukyFzR3BXBvbJy3QXugr8dUB He5pot+dOvrduAJLnX7VqIha0Bdx+/R0X/rWqXXnbaYuPXDcHa8zjEBUDsVE1hxaPVIqR4/d 14fA+7PhHChM0a2LqF+WpqRRU6T6j3TCRgmbUZTxQ1lnt6EEQeWW2cLpUBfM997vsrorwoM9 Je1HuW1TKXv6od65SFL9g04jk+sUY0w4LYFJBgl6fcVSwL2vcONfNXwzZmCpgeH6yoRpgrDG U7yUm4IghaYpNJFlZWv2r6M9a+j3Q2ZPUM9m+7ZEAMWwH07fXKnQ8WzjcJuo6WAX0nfkYlX6 m9pebs8umJv+Tv4pEWD1wT5So8GCgZh0O3shOSYXw9p9EU3JUB6t6IpNjWMpOkBxvuDC9/TL u4ltJG21SNbGmJD6XaKg2MyzqJwy2YJDaLQtYAwu4wpWPMszNXU5itxdgDg+ge49msTdtdXT 9h1bnoHy1kOFubJ3cuyHA7+x5qq56iqhDX7kawAYiLlDKROU2ozfwY5pbfz/yxxmWUvKwKxD R3Wtn+m1lSrbBFd5NUKsg8YJNzpxRN2+Q2VzVVbZs1xjdbYHNKO+5KyhAsPxGVACKE0isHwC 46OGyDWBb58Iup1CXrK6FVjApNkVRpNVdd0YlQNhC2PJQeid8hmlkMtey0XO/Q4o4jjyBBsD wsNaZVP06NUUUVwlamt8Eov0i3XVSCkzGP/1c5boXwlsKPZ0Bbroi4rA8P+ytf+urHSaox7I dW/IPrD3G1kgYsJkCnXprnVSyIXBXHudhZf5qXqIg4NFshUxv8BIvUK2GyttWenrWGJsegxe 1gcmZccDWMRHBrET+kaxfQMAINe5ZVgvR229HY0zJZISAEldPAKdetFRPaB5T6epaheh+lDg khL8JjRXwQej5SFSNH+HIzPzdCyRGKdaVph8wIBl/TD7S+1HpsKYRLTNfxOtA7dqX7PDUp96 gJcycEjpTr+Lw/B/7rBo0z7sJwVH9v37NnTbxiGTkSnWsH4wdfqG6tRWUIbwyNrc4jR8HNeA L66quyy0Nv9LyFNTq9uPNO8TbAx2z+9L5dXkp8tahSozs+DsfFvPKdNE+hZs1TToVziKaz2/ 41rchAQbK44IOPcVrt1pvwbKcasv2gKdiB+KQrpCs2RkTtDzmWEm5osBIo3k5PjDhVgjK0bF ErY/SVCFwu3A3SHpgaTzv2rmwSanLr5Pa8DFzQYqoA6BeawKi/ONzacQIL9pxhdZ9lUiVcex XEfIB7kuj3q6P7kUZrMmUTRI0lme8B42Erpx5jOCEh1WG4RwinQIO1/8SCCUznRLSZ1nvJIw CtFrj4HUa9pwR4zDCIx8Eq+01YocsuINF0kUgMZF1yoE8A35wK/nCS++sXHr9NSKm/UpOMSu Sosf+vYWNsfrFdDF0d5peQuLL2QF6GNppPihOM4GqEedAFsq5QEDBdTR/MZGLqKCox+cbxz/ s0dq1ihrnuOYnqIAe1d8bTubBTGLzVyna7ad0QcxanMwZ8KZ3LBiaXelpim8p8C/jgw9mO1j JzJWftMaRkER2/NZ8tcO70FT8bJVIxraydXg3SzWoa5JBDyT4hoSecQAmjRgYKEvpRsGohew c5a4XyCLZdFapnZ8G0hWmkxQZQQBOwMGPxGUXe42CZkEFJZdUa+mHvUbGmvYwhOR2zmNtCXE foUZx0lSz2s9/xoXVF+NJwnMJ5Jl2qUR6ENHM1FSCBxJktLBecJ8DU4lTZOT3e4X83T3FdAg la6jMzJ3L4AkIroOBRG82kANGPKhVfGZOZCnTZrDDo1z9LhGkX1T0RytJHKr0iL6xLc4Tnb3 mA5sx2nGVAKwg2mBrBy6n6db8HzfjBv4bgPjKC5IH74IyaZI2FdzZOHkLvw1FlG4gFfi5IGM SLhhYT00/MbNJ52xIyNpefU0zzwTV4i8JVcel5/dkCgaIZANBPQdJoVq5crvox8/6D1qqtQt ATnWOtfHbWxkeS4H0XA6nRfkoYuqYLx9Y+3szhEIreOC3kS/j2ktKem0kZjuF6xrMxmEE4zM 7G784g/Gn7XBHmylOjEsIf/O2RLo3y6+uh3a3bob96fRPUzFTuihSBrOqN3tubKHHXw9aOR5 WehhSDDaWbykF7NSmRIh1RsIUe2KkKrMO0x+qyFZUHDg5qjLrwzLVWNaKKwNXPgKEriMFHUx a0JOI7W49uhrPpee88R1X74UbEo8c6Vm9YuhMrmgtqRb5nVqqMLlC59x2krKFghGd2xcmbJ5 lFT1tXskIZlk3kGWkxpAXb5wmgM+mAjsGzMKrOUKvJ2fr+erNxyLMwgA9WvnrgjdG0Odq+/t njqlvphEKQRNlHoQXwa160k/5WMzpyi3lkCNGntH7jxmF7Evpt7ryzefJwisOgncTI2sRe/U XoKVQuNAozSX8sxvk8ZRYt4yiX+DRz7Pi4MPQb1l0a9tnOaPCdFzD7hUVrnil5mOaEEBXOti MzW4HFLG/3a7wiJvlEtFKyJ0u2OyS2b6jvleKYPvzhEOi5D9T953xfJ4VkhAuhtnXEYMev5X sogNid/627Wxpof8xsWMuqoeqnJe0bJAofkwHiFfSZ6onSqMJVAriCWvBIlJo6A+JqIPB72M yvpeWbGl3UDds/dwqKQrKVpMLlzYsrPcmxC+pnKf6mVUtNOQBzHpMVKU3fG9btlaII0HHvqn sKctC6erBlwkUGJVvpeRgMElyCd1El7ax5xc102Pnipw8ZDBHLIus0X6kR+YQP9zUTyV168n WdgR7d7llql5gItHyRS4gI60WpJdV98kaSGU9tcThupv/QaJ8OZdACZfA64swR2vS4CT+Ndp 2E3BToPI7NEYj8P1GqYORNNfKu2ffm8iiL5UbO7B0e6CzEMFYcU/ZqvfLkYFf4iNocQ0TiXh wj6LfnbES6AVq5WjdblrS8OGVKRk9V+tQD9vy+ga6PL6wEREsyKpu2SSuHsy4ivs6+NiUxb9 wK5UD/zU7640tT+9YCICIEHLwDqYDw54GqTn3DV3MIvSUVLP5KQbX1ECbZzEcYWS9sZaThrJ rdXQp3I2uqUTZ7XRhUwXPVatLXYNCs7IrX4K6haz7Xk7suYpm7ze0JoWQd9p3LsY5rCGkRWo I/t+m35o2k2H2g7XI465D5kVE/wKgkiuLuQdZWzY0G+KE94TKEu4UCQmRwuaFO8snuEiuten qZg1cwLR6U2JUWpDc73s3jcUaoN5LheuNnvaK9mdFwH6AvErKZgn+SXE/o7C0TM7/v0ly+r+ CXTGsH0YUGOmmKwoO4En4m3OJa9LfeC/iGRFsLgAcl+HQq68rHxjmUmkE1edOIJqDNgY674e RZhvuiV6ui0ndaaAypkWrujnVT1TV54pDNRxp7b1f998td5/cRHUtU23+NK3HQnOYh5WnRGz WhbdSUh4pb1Yr2BcHg1aA+DyOuMWpNQeE9oVpsTmbcwCPbbehCkeJHJXshascH3QkL/WXlat HUJeNq+FweY8p/M6SbXv5ip9NmtIs7fcl9W9bsIiLHxaO14Ic01sbMQyySr8p2KQDovYFvj6 Xa4Nia8+QRcBZdPj3XFdUBc5YUSFoxon8zzS7j9DShYNNP7ir2LHw6fSnIqgH6OD1703G40G fWoDC1BIQF47o3MSaF3Nvs7G0nfPCY13G+rkF77b//NkFxoCLMi4dlT1niORwrbZEbojTZoq G5B8Xm5MA9ny11a9LntM4/BOsDzaMCVs1btrJefaNcPaVYkOBeuEQO6sXeNawOFNMQE+VzKi THBbUiY13QdhJCnwx2U2+uZnZhsmHsU6CnLrCW6UokTvM4A7qR9uPDFGSJ4DDnczL8qXK5Ms UA9egAO7z0TZFqaUa0ivNgmTU87Q+9Ih9eRMiL2GYn0VRfznoi43Mtq9F2hyJKBgQswB+UYo gwX45MupqEOV8XyhGtqCqSKKO6y99qwvbztJIN5gXHFFojmDJBjbj2/Cv9kh/CVbmeAPxKmp 1J7bfvwRDAq+tK6OMJ3d0Y6cxCXtjHW6fV6FmRNzVU9AKAb8qUqNNq3Ad3dnoapVULlM20HQ yU2yHeI/NP8JDCH2R4Q+wA0RUejY9z0F3fqwar4nXfCdYA6wZRDq0QFjALXLlFgVvOCPdL8g tKkhm7NIZXvlmj0OuLspysgsa60Jz6NHkcdmzug9THsUuvZE4y2kVAcB7ydiMt2KoW5Wgf+i NAOsU/KIeb+ei+4fj/eqY8nDVRlJ0tdz+ftYJPAagZSiItpgcHEZdM11gUetUwxmHXnL+emW 6117Hy9Z4RiXpvP/s7q8JxMosdvbNyTyOf0ZBSxOBorJhYGzuiCN0aj7X8xADXfBpyCH2xyA OY4ibJd/KHL+jT1uYO33oDbVGXRMWJ4dBv1t+GU1LfqNnyJl/1/UJmi1B4tmN5oCRRsKRs68 O2euRASp83VaRgk2T+iHpgrWfj1y0v+4l3w7kGWqnyY/+vsuqkvOrE+zuA3CvXM0wxpUqmIL /Cph4YNh+db1o6Soqu+zIWyad+FYKFeKuMXWnZJW6M/obs9ZXXGXOwSqCBK6kJWB1/z148gf 1jU31EwcjSbbvaRUJDMYWbtYPdiZ5P/wZstJqDcaBVm4AWUkJhC9tLTTr1xm/3ila5msds8K CD227pi2t86WJT3LDSgkHQycCeGHsVUswaVG5xhY0i0EYtQxD6IZvrVjjx2B79M1Rk1IdSdO KkqedZXsWxP3diVQuYSSvJs1wQjM2Ykz/N3IdsTsrmTsWfsYjQ1XFMrv+bKMsCYTYtP1spPa ZL8GWwPplKe4hzbc97uNyQC873LbghJURYA3pTYoqZ4mZiDMFEUW+v3bRpK83/htFwhgJHP+ WuM0/mEIgTN2Yxt+sf27bOFioIPwfVfgR8XAo1ex1HBEGinOh9Wqyl6Ta0r3okn8m5XdYE9K aPRMm58KrB1Quy9wX6DbJ+oZ4TE43JkQNaPCJOJrVOal3NKorSkajUoeNOj9WcdC9xGGeeXY YZLh/SrLWtHgykR9yIIZXZf0/VKBs7nUpYQS9+tSwWWx6yRy4kb6ULM2yCY7M8L6BeQ98ZYk qTVZagzTJm1RQsyDyhC2+QPbO74UPoiPhHZr7VzuW6QHWaS4/lffrVK5tZITraH/kOnHYvd6 ahpj9jtTXpFUZueC/YD6WlqvWQsHaB+Ta8jVBJ39hPA/V6LnnCHCQLCWYNJoep0rFfa7mqxs MWScLkc5z62I9iefmmjbuZTU6zb+tLM+p2JipIX8ugT+mosvNLqtNT6VB1/Gp7coeu10hdLh s4vUY69ytapJnJgL1Nc5X2cqZBvC1HRPw89ec56tH0eP2EI3XwWZuS0XkVeT7KhkHCj1bgg4 lqfQPuZtJa037C9qaDmoj+kwf70nlncIMCL7n22IAkcNKYK4Dd5eXZPh7fhh3PT78FWVyYHM kNUU6pfGGZuO5OPQBi+h/A0OsQKbphD39YEsltIxqWZESnCeeBnxqytpw4V67kyJbQtp1hyn qCnrFpn38d4KQmyuMeLeP7BiXdxF2MdM2yLkXVLfB7Xht/9PLuw2ZbBKYnK/StWjshEbIx/n qDM4WelmDI7YzO401qJdJIcRuVTyrxKCyResmV4gd68JA4UfR+tK/3RREFscHXDOtn0DkcZh f2c8suuvmnn5mfcrYm4Ir5CzdpOrTv12s1Rb22m6drrPRRsXcJrRw44DzttiAa52cT1jXEIm +oBJD90c4uF7p3pbwB8S6jtv49xqDzIFwQq9/fkSp2cgaqaTGzqM5V68PLRxcrCz9oazeeRR fp+MkchNfdma2jGnqeyRcoFkcixTfSRUW/KasfY/rRhpx37xd/yA9iuFvWeEeGxWM2aUp0DR KgVENMhGVfxPar+sjA4LUyfegMTVVWmvIpP+qvkPL7l9ej+zHu2QjIhywVgr2dVYYPBdxAAN /KyRYWSFuPDHPMdTCF1F2nQ+zkY2SmBe3mNqaI9i3j8AqJkksWKfh9R1BV9PA1j+LaIh2Tg/ T5G8VZ1wGQWP05E6xXg5UdQ1XK+B1rkEuEDs6GK1U0Iou16NCaTvII9RX0k6/5aFkBLo16De q90Moqcopgov99mYXBGN2KJ7EJJk2PAXsllLrNhEmg3+JMq2zWtc4dOCUsyAjUYvMA9zB6IJ p4bqD1sP6UHHCirdLfFx5HGZzoqT/pVomgQt2NlGWFPUlf85H6wGSsxQWvtComMrip4S6Vn2 4H7+SIc/eZJ7lFtkQUNLz7pXQ5hPPFalW126LOsj6/d+/btq7IDmwD6qBMfZYqtmkt46edhH HvDVc6A1f4DKdh+LM844BMiKvRMRoQr2PrlpvTKdAq/sJhE9hw7Lt3sev6UYcwJOKDoZUvel IiYEpG1xPGnOpbEjLT17u7U3EfKIfKt7iJq68mfKpB1s5K2+AQZ8Y4Otb+xgkfgxrJLWEwEN D4o8z03J4D5SZ7b31NyAf2tzJZMrrwz3rkiNajk9ltLE3r0QbNKWOSqDvVwvzCmmfRgKDeeo BdxiY8yK3wyzBqC/I0tF9hsS53gwdgialeRduI96YXl0ly/f9BAnT8StLh7SSvZWEtFDvWNM 4f3DcJzb9aQhhhXlvN/iFJWY0gCdD7+CGMi0h0fwx6UuJazVf20Ue1Jmaxs3A5nOvXw3guSU gROxfvvLp90FVIW8FHLRnbQ9DF/xbVsSzV4+TDvpwSnELYH8XirR6l7PDUqXVLSmV/i2Uzgq k2lXSQaVcMvfA7DqxTIy8Th2X3yIxg4b2YDiMMog3OR4mkYcR49nfdSDhW5vlR+NDlTAsHyY bYpnjJrWdw9x/iI92hQBlcyrQ77oJVelsAlbZr7xaF0+sTjyre3tMbUNgEr/2QirvklSEJdr kh71BxVRKNnz34tmUR9IlFfmb6hiJslAP9/fpw6/RjRrpldkd0Yl/hkwlmyR0KLZcvp9sXUb Z3V1YTc3nPdsF+8EktUXa608KsGq8kpkSpW9yA1GjxvAWjIGKqmEIyTd3nMgp8Thn4IJ0Fa1 PSWkuhIWsoumlttHR6O56/U6Bxnbxir3lwFOEtvLQEU55Qo+EDp738Mic8TA5qSvFvx8Fqgg ESXJ7lOzoUZD4J3u7APpzCZb+gY4OnA4XlNTO3uBkmwiS9VnERbi1yTVGT1wRIcPJLOhK08u XQRgm5awOIuZ9GTinh/N2lHS+EhAOngZ2lwBkSZRw0LfS4WNhr2p1yz0Gmp2HBzCNurghvkJ liGmkzJt+K68Sn/TlDwLao5k9yBYkJGulcOf9DF7v/k32IRbuI4y+J5Dacf9fpe+2CoDAH+R 4SaesDbfo5sQmJtvSttrv0aUmYACHDK5jMzbyLU4nwn4BcQr3p+KHPT6XW+2rIhrhNcSdais szmWDNgaHxValMmf3fa/IWStc9P/wa1X4Wdh50lh8mRB6CVCtB17JxeAlAiFfSIuS2oR4LrA ux6b3ET+619hP7OK9UYLSyINwvXsy2YXqtFCthYFRdNUkoXwQLqxvOz43taTnI16JXirmbGe bIL5C6HZgICn9/LDRPKXV/MVMKJPQGMeJOfBjz5wOsQD53mYU8PhsEjyIqb3ERnluV1oWDkJ n52BykVbb6aGsoNOvvS+J3uJhoC3tZo2/pmzVpZ4cbx8KrIEmJs4X3vbGXZ5dT86q4kkU2Kb h8nBJZYgawwI3BQl+AtChedtxAhEKf3SMMiS7y5yQySpGUOJZepyZelW5zySCfwmFzz0QARL e5E0KCveYd1v8QHhlp/rc09nKacT8fRD14htsEAmThCFhRqvNJl8tser+WAKSJcdTp8EybdF o+PPmHVGMBZAz/ng7hNklWF/z/xuWO0A51Xa3NSyXcTdFwbK+B5ne2c371Oy1EM4g844iXY7 i/TvtE1yYkG0zcsUJ6Mep3IoUQwgsfVfXnnyBSwbVPLdADcPCCZl8qMZZGItdT4bCGihIMD1 NHPaaT5P5fpG3rb0KcwCUbHRIgW9TUuuiMsvONXHhJQbpse6BkBhJPUNQ6byl11rD/Dmjazx Gn0j0ZjTfZEsZ6DSjnBXavLGRceV1570Cu1t222Xq2BWU+P6psn1vZfaCHPtpRS6YEPV3uHg fofPFsRgI2AT0Ap/11kNpmHvi/kNE1fAEooE/kCuoYeYZxY1/Ee2tt4tLHm+MbICvjZCm8Xx mR+k7CRvfDYPqXiX13TPg1fLE4wZIobwuxfY2tvN3pln2ftcYCaGhUPOuyScyqX65c1RHY9v SZXudaCe9fUzyFGD73fRC0CjIOr7ESgqR+2vAFCDcr0ckDVcTiakOsYUoRCY7A9VYYkLnBmy TScI7ycbKN98hZerPBBagZWCApgUGuTkv+yjxLnO0fo6G2taovkcG90ePptJlYkNSPxm9TJ0 pRqmBVMNNsdkPKWYD/sVRwKw7x0phhNVCto6BREo2ntziQKbtrvoqRxpfot+19002Bb7IGVU wnYAiwQtwBgfdFAhwrB316qTEgWiE5AeSOnvdTiegBcHkyBDKzFoyfGl3LJiM9lwSIe6hhkI rZnH7JUfjkv3bCi0fIrDz0dFtbrEyVKDVG7FdzknyB4a7WFozyA5QTwlLx5/FTSkH6lbycNo AiIYShv/Holk4+WbFEVNeBzZq24wt88wzcyB8fi7gKwb08GtXqwRbDWSZZ16BAwFsWnzZECd pJd8nweUWr1Kwii2PaZ5o8YBObqD5me4OI0lTYQiWHv1WikH1JTfsarH3lD3xJL+LX5F9zHl R/wZ5jCOsDDY8kJZARqs0WPaxyBAMlr6vpzkts/W1Qn8KrgrmdX8b84b+E/gjqxxdUIZh7Z0 2sWgOhpcU7bT6Y+8fEQ6oFTeFbd4RlEFeaDtmUSQIPS9XkK2TsbIpt16lUKjpUoVz9hkqive 0RoU/b6YWJU6dYco+zIcguB1rybJIiRKRykPQq3cxNvrzxnPCLtACF3QyzmDs7WiSiXzlC3d mUMiqiJRJngu81VJ/6A79E+t6F5EohnWagNyxnlbb8P9c9MJ9b6vBFoEvg3kSEMjZb1qt4rb p8GYJPNmHq7ZBdAdvTHpUUTaR9ICG3usOpo/SygRs0+S7o2QkDTE8E6n1esSdJqHFC65tn3M 8CAW2KkW9wcU1j2l5rscCs2JdTzE6ALRJCq3l2M4QGP24NXeigMJ9NPsygfERupS5CWDm19b HOwE9+XoUO5zihyz3jai7lK+suOm3/qAJFGVOV4/+p8cFNki0WwssBc/hxXWyiDABsI1zqUk vf3F3IoIRLCbveTRf3obMBxaDvViaRqb8y8ulhP3I5CiKhaVs/WDl+cwWeeF179Z5umQbbsK vbG52eMhi0fvwXKyb1PuYVJ528WV/kHu/qsHa4YqiGL5rf+jCRs5pw1SaRKuoNWFEQb5zXo1 85bCGqv7VqhVyZRSf0pJVKc2ZwvsEPqSiZKy+NBQ3iaVQO+cEOPlmmpFNp1OUgy2MGxgFkWq iBhv3WHPFCzsR4FqccEoNYgxLPSzjYvBdvLJSwC1sAsopUvC11CDIHa/fDzAF6AB5raQlsbW SXwJj1oWWqwXxvWB+CWLTGGxu2k3r50RcLCyr0gAnNpfnMQRnIjEAnsJS/9VpQyc1AwvYPoF bjFSjmW8xnBCdJIm0VhFvm1WakonzgNDbNFULTyJS6Qspl/TAnB8P7uacUzmJroTB7WhyJvc 7Me/Re9DPlblyfHTDcigBzxu4etsrDsaOqJwGYYAhSiFivIJ0syhwHtXq8TU4+W01UzrVnTW +u6Nk3TL7Gtel6Obukaq4z2Rlj7P+g3w9iyM4aaZGgYiI0Trx2x5ZDKaJmo/Dv3ys/FU5gMA G2RrdDEadx3KsPMcn/ECW3AwqMK4+SR97jflzeUUZztzzEuXi2rYbtpGJw/kEuJiNRK+/hSO 24rFsl0wqHoOdjuQKPyILJ+Bv78+2HSgvo0KmBXiq/uev4dWo5wl/LECbZ6U6V74L+dc2USY +MpVyI3HD7r8TMAH1SR7o/7wyaPa0XLxP0Dh0lDbEwW2C9ZkB4llt/p1JkDkMat94cQxz6Hy i8OAov1XmlEVNzPucgKxTku6eFQRtPGCteFK5dUeeZyVE6bW9noDLzYEdfSBMC4DBfr9q1th rpEl2nXBeWVkmRg4WhZBNjvEZokSD0CHNEu64wtJ+WHJXHo5r5VlhjE4cTwfXSedijx9XoTA G4ky8grT6qWs0+mBqUGXz7nvPCNhydbIuflpgeAQVLniHg6z2vXnBKaxFWF8Dlu1TS1JPnzc 9FkFT4iDp3M3d+ew3mhXsvYpBQ2JBZmLcXtQW184oIN42ZChJkZYwVw2YVwVP8h3P6210ORN ePx+aA9xAMlZI4zURplWdow7KbwQ1V1Z8MbQFScJp1FkCLdjBlnegdFvrE+i74OuMv4bZ2fd V3iZI2qLNLH5689ScPL4oWbLSRG+4klxY/9qVut2BCPDSw4ABZvy7tUTUYVJNap8Ck/Ok3uL bBw7iF/aHC8TRk2c/9RhjYLtRE5OXDVsmUlLh1Eex+GqNzkM60in9S1BXBGFiymLGl/g0Geh 36XfYWk8mGHB3gtCueI5okCzcSlA9rlgACwCtvTpYCYnWcDQLr0J/fq5xNN4pckmSJQg/PSo JcBhN7SkKU5lR2tl61nPxKcU4Tl7eiRFVE0xZC+uUT00fErpXZGdKngdb90Kj3bMOO52zI6y Vc5EtWrrj9WVdHU/wtNWarytGvW7jVI5EfxH+7gY0bbT8AFYc9+AiEXWkBqtaQap15aNJWZ+ FivJoqXa8HroTyDjgVI8xZgE3odNJlt0QgIORqTxxOix9UAivw4eC70N0AS2/URqQGTNRTem OjhPF9OeEBcM2ZrsnvFH81y4AZmBgxhlnsxujpNnRS4z36Qxn+ZsFNQeU/oyU5iuk2Rrs171 CCVygIvws92MHCVE1CiKiVKqbHySdczTuWAWPJ4jVWYYkvgYG3GXj92qHTYsjPxjqkUQPn4q gYyKsKt2f3gvXs9XT1i920G98KHBfwNp19dwP2p51EMv8yMTJClwfr4bsyVC0Hn5UJbfkn7f Tc2Ktk5AYlWKprxln7Nf98JTgaSxb3QqzmmxSqQulm14RgfsN78ASLkBPIOKMYuJlFzGNwzd 7T7sBfaqcKg+z8OhlV0zaUfaWrE2/aqHU3RDr4sSyj6fD5WAUUMnCQu2rr++F13nz5RFNTJp oBpsOH9nxRs2zCwTNo8hoP0fMERFVUken65/hQEzOo/K2y+2GwabVotntSDb7SJUpSScLWqf 7SYwkY28G5ZT00XPNpwvu8zFNU4Q4RtHgN/7X2nAXfqCtlI16NQSdNSV8wL59uFWzX3gkyPt OP1NhExTtFpjXMphEQ7bnokf+tcmmQK3bQ2OgqzorMCk+FOYq1U6rCD4zzCvXrxwRqMIja// DPgk8f+Sqxy9OBaMripKJjERJKFh5XMsWbMOCEAek9StPaXlIJxlatiCXhiaik1IdHkNCQ/l KdRqKrCXJANgf0pL1BMEQCl2kwXxZZGl5prxvc7syEYoBbEw/c4XSSHG9y0YpKcXxYok1WQu ee5VUq28C11lETrrr5AWZ0l+ZpcUtmV2JslCYLsiLdN+4w+JWnJGCA1Uk0RugL20Ztq9KrDx loUOnAKTuOqoSu+MNFTiFQeJghZH7xuM+CA4KU6HC9xOsm9sHGxH1pJg8tnznqFT5OTLCqtI OwMxeGb+8TvzCgfwX7QC1tKqXExLWMURRs6k0mpgM5iQdt5HMAVEP9t5YLIA2wPb1UjoTNLK wx5C15NhEM+WQfKURP/w5iHAdzKTTnwhm1t5d3Lx+qBDIzi6lIhsSpDqmVNXUcuQ/mYTlTDf 03qdvpk8ySL9QWhoCFvIedFbJG3QFhk8P9X4nsGBtpzpkwx1JJAaJEu3w1ecGvhRo7JfhrZm tJ8E0bHCtGHfeozsX9nCme74SD8BFgXsVa8PgtCY0MG/JVGbL/tCud4K32HyuFnwkkw+1Fvm x3Ujn8M1XRWvdLkvkApfLJ8RzKqZYxIG52hfn12aAl1yeyWfEDcuhkIEq4pjjQxauj+0kaMF aJ9QU5TQXaKC1bltVbKIQHu+JGkWOEVZRis3n4k8RTHxMNSPFKtREA3Kyjmb091C/LjsZ6My u8BwsT7ttE1fcR8t5Q9AYE6L3mW03Q9flqg7PLIEYvsoukrtOEC8yWRLAZsAPL1sFdLLVmIq x1bGbzowwJWm/0XIH+8Ewd08X6kBrS9td6RAQd90154BSvwSiQQ3XxmvICUDFTnPxmrptzei +db+73e9iQ4rwSAxmZeplI/Blpluepchj1n88YxJBCa6U5LtPyI8OhYcLQKP1RbYKZ+dP5j0 XaHvaRVfrtT2l1UJyr1YvRPubUs8Xr3ao5GkvUaTBbq6yyYSw+CYhTFH8N4+j+bvUX716pXe P0R0O3jIvWVBJikrLuA/pgyTvIn7Xv6krcmDwA1q45Q43Ruu70h6Haqse6Jh75v+F0QlEQ7N sc1G1EBq9nDU9YS5rB1cps7JMw0Kejwg5CgfiVTCE98CIXZVGKrIxezQrihbeoTyMkRfq9aQ ACB/D05xj9OgwTkN2rgqpkUz2DbfoRIixsVhuJy4XOCN+xAUMLPZrEUfpvI3NBhK4XtYABbS CM8ayvu6TWDXvYeTxUw5cS3TGrTCA8eX5X4rjJEokbWpbQzQPRQ8UI6ih7vzXjN1pzlTJi7q DaKeWU7leDm68I+EoEm7f+030YdMvq30Y3HzpKOXXWv2kBu4CkZ6H5RWBOM5yW1p1RVoaxCo P515YPGKzgpxEFvtTeHccf8gI6rAw7YqhB47HXAEg9KKpnS4eIauadfAAWwcwMicqhb87mcL Kq3fPM0Da+qPRs+6BT7pWM18pyVUqOmniOIY15MfPqffB6QkXPkKPz7b/SVT6iGHj7XGZewf 6a62gw9Jl1lYyB9IUr8OFBQONUn+F51z8RetZN/qN/fULTzDpiMhwsSXyf3MiMyckHfo75K1 pTB8U2Z1md7BdkzCDXSjEp8x0Fib43nPoAIpm6nrY2kGd/djLKgwqQ+uWeKumDJ2dPWyrqE1 AotQkxi/y4q++9KTLM2/+xtoWeFagQGjq9JwBXHctfhWgTzJbtu4h2m228Tk+qSG+2MiDGWe wfZiFgHYrt2urMAvSbLLu8s2V/ZX6NCxgFzfealDlMs8tctfp3C0kJx8mrTR+qOFkwdGr2hy yL96KjGx3aHqXU62W1CQzrOWoCqXQk+U/IBumlPHQWXaZMbAx9cl6ewQp6s7VMeKQCCSkF/y 3Az32y5NiaHwhVTVV7qk50rlWdyjEoGW2KzANa+5Lm5FnXBJqTXMx4hKuekqT4KnvOlUv8M3 jWMRIsf0b5Eqsr8A7rxoYIbzn3XR9rqDDxZXz5EYzaf+Tu+yl90bFeuOYkio+5cTeG7dPqS8 q87u28HaP91HYkOnmLy2/8h6gD8AqDJuu9VKLxIEaC+Cy+l26shFkzB/+w6+eWa92vW9O2fb 2e49JnFBt0N5EGjSRdjgil6yJek8HlQGkVXU8Uass7zkUaFDIV1NVLRn10hgCHsdvSax2zKi Ueusd2ApYzc02cisVcjAlm5B+4xIFf8Kc/2Q6YcXDc2ZbmWDVIEN0zmbrhLJlwTvANIV/q8T ZzSiQ4KXuKAxPpKM9BQj9lzHWOlYz+9H82HOxJ6rij97QK6THBo8+QiROjd6yZoNGDYhz5j3 al1duG9iNa6+IdmUX4C2+cDSr4SLM1OUKY7tXjhTPqOLKVGcEvufXUazeOYp6sOpyMtYi6av jUfbOaIDJgNVCYyCd++UNdr0uv7vwAw4df+rsXAf8AmS6RQBM6A4O5lghT2mIDSemc7yBttk IXdsw3RxvH3m6pXWWHXCVQl1Ho7oTPjCZr3tIzcBpgdyEcv4Ez+24cZro73tuTZxa6sAaF9Z ZVyJeGl7TKkUYisXx374n/oMji62jRnugsV7GlUNrUcxotPcPPQ2DNtrwON1tt1mKFPBUI7B 8h9IlKry/zQ266b1Yl2alDmyz56o8QgweLph0eIiu//1XxtiMz8Y1Esq8hHlYxqRuOUf0FFp zz/FFitulRcLhyRI2GO26Mdm9YVDnbPAMa9UpsrSEu/RpYtGOkUeByH/BbSLcWV7D/fT/nCr c7eFw8WUWZ0pDrCc15KZyQhv5SBi2gYZIpJWdwDJuoZcphp8avtfJq0EnsldE6/riZC+7MlR 6OUb+xLdGeXEIdo5ve2wgVfuePKN+wQ2D8mflra3+C8tgip6Tkq4QoEkNmygFFrrmUK149eX WFsGLKCrmujQUTox1m1DKzCOnSl74NyWvkoj70kWXE5H3EochYbk0+TjBqoSD6lkNnK0HjpH ZJ5T2Uor8XdHrzHEdJhJvHX5aQ6VMSgLXUrZ/M9/U7e4btYU1YN+4KTl5P37tLYJrNDHwHlw TXRLeI52N7bPKV0K0rZl9pi2D4MOJ4JAjYvQGeYzv2IKJXlytHJdh6PlihF3IMNefT+QimPZ G2uUXJzrS4TJ9UMqkRj3yV0bpCnsnt9gcjj0X6AMuxTcPtH3GfQPc5DhPtotHkXdktxyz1Ol 8Jo5zd8USe6MEY5DIQu+0SppGQEzr7cIsvNybDBaHhYz47yR4vwJLxF2lMC3pEQ3a5sQwPQY e6EufXJThmGWHxqdq4t2mUnIcLUoV8kXERu6njFiq6sANNiZYmacV2CJ4TzCtc8NR/23S+yw tMdcwM92ZRTopRePG/z0rzGHmgsdFCidMeCp2Gvnv3nsHjKvotQXM2tlCtsFFHkb+2RumuVb jsFHvAzq1+Flv8N4/Iw9vEVEIBM7l9lRJ8hn34bFn4hBCbTKO68l3l6kyXrHUola9C0lT3xK 2QWyOFSoblS/MTEffT8iWV/Anh7unpOdwT0ReMwEs8HfBPe1aVOkvql0KlCrT7DpkR+QCGH1 9fbDxbiDW0+pAA0p0PdFRmU1I6FtODThL8k0pKg0ebQKi+5SGPEwSGHY3O19wtAZpOPATWDl RCO4UJrNLQjLvimo9pPDQaAXKvWX/xO3+QWngrXKDbXpXLWXma+YxYiMjnQkPfvjKQKFVVGh d5xSTZM5Dn6Jo8H4tiXvXIg3AvK70QJ0p2I2UdAwltLJ7CX96eMqeGc9HpMD5j6ZovsNOv9T wjZGDixnLSBcZaZDNyBaY7r3yXjC0bf9N3LXicoPIUiDTARPKWFbMK30EBsBcm+YeP254cCa edH8IXNMZv9JIWVSypqEf9OSQHqYC1e2CErIZAACIdJtLgwA9R0y2nz4EvUVzpu6d3lpE3ys zallo7H1rBrBLgBWOTKJCjRqG/bq+32alHd7cR7UR5fKOEENLTJx5WsM+wv73HJcrHwI5UUr en7XPVgqzLgSx3AjqXgopVju7Yl4Cxa8z2DOs9NLQeluK8V3Li6Zm9QfD45VBOolH/p+7kmw XqZSTLrV8n7sxP2/4FIu5B2UyJZUmJCeD/r58UfRB+tZHgCGQrAsvX+0+h0d+eY5EPXEkyXN ZGQ6HX5QTquOQxmc9y2IygvbbIuCF11AeuuZ6AMkcTfRHzdPR56cEOcaGUpKKplfxvwTu15M Iey5NX5K3uhJ3XErPsKmPcL9/ZLufWWpiN0woL6houNLQG+vYr8CoxC9meiWSwstMof1bi/4 EhKDq5tktcTBypli+YW6/dUkrSy6ajtAKToAag/VhaOQJDjxnBJFB0iKzVilwIf0cMHqPJ6I WxcsgMvoglEWz1ZOijbS8tUc19wBBTp/mtOdPxn/ls4bR0wRXs9qwB6YY28JNuu4yMe9Gf7v Uc3MdsVpHmh8QpYNqyVPyCQX/2pXy4wjqODbDURrHQL586vTSNSyiS4leeUeOwJEpKy3h3ir hPgVO992gl7fULPi/wkvhDSN1jmX4w9fZvuRH6OWy/mjAJC1WFMcWvJqySe3hanPuCaLNY8y BldiFiRtAMaa0j29i+wtCW6lOqVHzdnBgjDvfLv32BIbBgUlJOJLySUyHL5gsQwFV6EaiVbb y32enn44kgBD81HcVlQIgKal0Chajs0AM1rxHJM9Yzbhx9WUOohmiLQLBUCIoaLtq+yXkJ+Z B1+YQUOAdUligusM8uwudMv3FEzEvWX2+9ER6ANoG3U7A6S5jpVYp2Mek08wjvpklqBojN6t PpGbzAlmAX4cmsyI/h4vPcwkOLRTifuPB+vRgZtfclxbdrcUwTkVIqaiPGSaxumRMBRTKvCi az9A3ni+ESKYfJoqioOQ8TGII4fxU7dbssfrPngHjij2yloJ5w2FUdDXSxVdof7WO790oCHR LWmLcMqnbeF2Pjf36VG9VrQT//AP3CEhJ4Ccji08rrRvJHZ0KRD3OQQ31QRyW5VS8sVj145J N84uhsb0fAEI4Y/rXKPUzhXgBr5Onaq6vzsC/+9f0l6DCcd33qDhBd7S4kqiFgpVzqN29J9p e1DIQZOkv+AdC8RlwIgSeY2X7nrUyA4MHRZpk8ctY5nr/EQ3kgIzvFYnQ8OpeYSZFfBJeret 1HBrgd674zANppYVn9QAw5sI2S4QFUXtd/1xkEQ1MAH9QbzZVbhHhT09ZTHx5y189ilwZIW0 nSmQ2Epz2ossjPS847AiRBLKVbKgitk7nx5oN8GdT0D14MQyDjhemll5VOZgWbmca2Sln7G6 3dY/x5KxqfsYpaX6+iC8XatQwfvMTn9Fi1olylc35frDR7he13m3U/I7ro5rmAyzw67unukC 5kNFWJO+0NqZ9kvsnZOyj6ctafPAN6rnubYBIL6qdhlcPyWKYb1Y70iugajUesbO9e3eNH3o jVN7S47Z/ZozJZ9/mJz2bxOfKpKW50ppyO9M442EW4FIarXkcbDpbOg0nIHw3S1cuo14LSWU oZ03IxxeMtiKpLF41YpbpWHsq+3SBJ9DUxlPvrtWqW+fdDd/TwHuXzxsR7B5JOsJtMtET6di Ab8SCmX1E27CNmDYGDpCFI2P3VtrptVDXwAuHzEVPvefC8+4QIX1hrKSRlALIQQ0VjsVAkJf b/nQY1P3hJHWIIrN2shTMV1aWgPHnTDBdyHKV4TxpPbaYqN4f1r4dBAVfpr9/HSuRPVmQ8UN t0a/FKwoPQ5Fk4eaw3RZbjCXr3nGfmDSAfTx1BYh4Qi0fd6umo8VDAV0brzjEfNbk6AKHaHg 8A0vhNc/JV/qZQFjG18Ddd8gMqD5Fitq2L7IE2V7Ftim9aHmhM0W5hSjxOKNDsvj245QkGwJ ekIdiWQkbVdAdyEySSS2+N+1HLQo8Dj8J/JJn73AQEpk7zdlKuwIfz2/qNMziR4OpHEy9wfj X3iq0cpSA24PI5AOVjtyXji+28GC8jly61oLVlSBhNQ7avK5dS/PyNDfIwufH/7jR4/0Bs0+ 2UZcJ6Cx1f2ikzFPyKotZl5NUKkVQF4TecEeIwBjc2I6UJrNdogUNw9jsiZq9DczmbM5HaYX WzMejUTFO55BIv9y0dFIxAFCwDgmOqs+hSPSKVyAF63whpVVICrlxGdpq9gVQL3X7BzUmBmT SFjbyFYVcoWuZXdADHbwplMINkO2WZ/6K50V/kc/HmkiithpVY2JJ7/E0g5D7afnKay4haZH fDZeXKKKl7L27+xv7ZBi6+B9xZw63LCSnE+kosy4bmhj3nl9K2GrA+sZTV5/pB5KqKTNLp4P XsCJsaZ7/37OFIFVqUZsEKEcWa0aAWDi3pIrzxhXob+J9VUcvAqbopoqW9RxSlISGu/KW2ct W9Yh+J/uRwMTEblAziINY1m4l2NdeaS7sqA/GaKtvW58jZ2VaDfxQhWxdoCCpXsLDH5UnECc QJE7Q/toAJ8S5b2WRVdZoBSfaaZctKcr2Wl3tvepbm4+ny8QYPasCFaUTsEMx0Po9LDbK9tt EHb2M2WjyLxA9XuHI2tVARQtVyNINDaTcDmEXx4NI0aNEjhOVfX/H0sg1/y23qFRQdFvHAfX ysLmhEnZrzMVeF5rVooPSBCCXYGp7sZ4tcaRpaXRx/C8kcGMf2aoij76kvx4XHUUDQNKcIVY Rrja1kHfW29dMbXQJ5uMd/qEH7pjwN2G+KkmfVR4Xx598LtLLf9RCsZxWQmmKmrskaXh6QZe yhlwQA/2jskqjZkg/adFIZAg2NKgT2DTdut3DbGtLx0eMEBxNhWDdrqITMlQ6doONxAmLlF7 SGaEsv7BPpRAlVf2777sJIEWtbbw+Ph4xI9qUdGT2yaGPD2W5LAcIzCZgUf14phri8kFKoXi cRmhQTkQPiLRlMr6BzEiNVVHZELQH3qDyWAgsf0Db8sO1oqURMxWlTc+goUflogXomzQbWjP hMMgOjPR8rC17P5wH9e4/LBOAMAjX5fhVZXlG1Z8EuYsYixnvWyergLLy2+QroOYqIrjVJXp cfsKzfQj+Hl8qubrLGL/5C++QTDqhvn8KXpIjCMcGSq1/I3fhaxOV0CTcXhEqqRaUOzHtjEm BEpWNHmEEHI51jdBO4vPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABg6AAAAABdg+0GgL0+BQAAAQ+ESAIAAMaFPgUAAAGJ6CuFSwUAAImtFAUAAImFiwUAAIuF iwUAAAOFbwUAAImFQwUAAIC9PAUAAAF1HIudZwUAAAOdiwUAAImdZwUAAIsDh4VzBQAAiQNq BGgAEAAA/7VfBQAAagDonwQAAAvAD4RFAgAAiYVjBQAAi7VbBQAAA/WtCcAPhIEAAACL+AO9 iwUAAK2LyK0JwHTnVleL94u9YwUAAPOkX1dX/7VjBQAA6IkCAACDxAhfg+gFMclSUzHS+XM4 SHQ1eDNmixw5gPvodA+A++l0CmaB+/8ldA9B6+MpTDkBg8EFg+gE69cpVDkCg8EGg+oEg+gF 68jGhdMAAAD4W1pe6Xb///9qBP+1XwUAAP+1YwUAAOjyAwAAgL08BQAAAXUOi51nBQAAi4Vz BQAAiQOLhUMFAACJhT8FAACLlUMFAAArlT8FAAADlYsFAACJlUcFAACLtWsFAAAJ9nQzA7WL BQAAg8YQi5VDBQAAK5WHBQAAC9J0BehgAQAAi5WLBQAAK5WPBQAAC9J0BehLAQAAi42LBQAA i5VDBQAAi0IMCcAPhKAAAACJSgwDhUcFAABSUVBQiYVTBQAAicPoTwMAAFtZWgnAdRJSUVPo RgMAAAvAD4SCAAAAWVqJhTkCAACLMokKi3oQiUoQC/Z1Aov3A7VHBQAAA71HBQAAiwYLwHQ9 iQ55BQ+3wOsNA4VHBQAAZscAAABAQFBSVldRU1BQaHhWNBLo8gIAAFsJwHRNW1lfiQdeWluD xgSDxwTrvYPCFOlV////i4VXBQAAA4WLBQAAiUQkHGH/4I2FzgUAAFCNvdEEAABTV1D/lbkF AACDxAxYjZ2dBAAA60SNvfYEAAD3wwAA//90Bo294wQAAI2FzgUAAFD/tVMFAABTV1D/lbkF AACDxBBYjZ2dBAAA6w6NhbcEAACNnYcEAADrAGr/av+Lla0FAACLjbUFAAAz7WowU1BqAFL/ 4a0LwHRWicMDnYsFAAABE6yIVv8PtsAKwHRBPAF0DjwCdBE8A3QQA9gBE+vjZq0Pt8Dr863r 8KwPtsiEyXQHgPkBdAnrCmatD7fI6wOticGsD7bAAcMBE+L667TDVYnlYFWLdQiLfQz8soCK BkaIB0cC0nUFihZGEtJz7wLSdQWKFkYS0nNKM8AC0nUFihZGEtIPg9YAAAAC0nUFihZGEtIT wALSdQWKFkYS0hHAAtJ1BYoWRhLSE8AC0nUFihZGEtIRwHQGVynHigdfiAdH66C4AQAAAALS dQWKFkYS0hPAAtJ1BYoWRhLScuqD6AJ1KLkBAAAAAtJ1BYoWRhLSEckC0nUFihZGEtJy6laL 9ynu86Re6Vj///9IweAIigZGi+i5AQAAAALSdQWKFkYS0hPJAtJ1BYoWRhLScuo9AH0AAHMa PQAFAAByDkFWif4r8POkXukY////g/h/dwODwQJWi/cpxvOkXukD////igZGMcnA6AF0EoPR AovoVov3K/DzpF7p5/7//10rfQyJffxhXcMAU0FNUEEhITogTUVNT1JZIEFMRVJUAFNBTVBB ISE6IElNUE9SVCBMRFIgRVJST1IATWVtb3J5IGFsbG9jYXRpb24gZmFpbGVkIQBVbmFibGUg dG8gbG9hZCAlcwAlcyBub3QgZm91bmQgaW4gJXMAT3JkaW5hbCAlLjRYaCBub3QgZm91bmQg aW4gJXMAAAAAAAAAAAD/paUFAAD/pakFAAD/pZkFAAD/pZ0FAAD/paEFAAAGAAAAACAoQylJ Tjk4AAAAAACQAgAAAAAAAAAAAAAgAgCgBgAAJ2AAAAAAAAAAAAAAAAAAAC0jAgAAAAAAAAAA AAYAAAC0AAAA0QAAAC0jQgAAAAAAAABAAAAAAAAAAM6VAgDhlQIA8JUCAAGWAgAQlgIAHpYC AAAAAAA3lgIARZYCAAAAAABLRVJORUwzMi5ETEwAAABHZXRNb2R1bGVIYW5kbGVBAAAATG9h ZExpYnJhcnlBAAAAR2V0UHJvY0FkZHJlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFsRnJl ZQAAAEV4aXRQcm9jZXNzAFVTRVIzMi5ETEwAAABNZXNzYWdlQm94QQAAAHdzcHJpbnRmQQAB AACAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAwZUCAJmVAgAAAAAAAAAAAAAAAAAslgIA tZUCAAAAAAAAAAAAAAAAAAAAAAAAAAAAACACACdgAAAAAAAAAAAAAAAAAQABABAQEAABAAQA KAEAAAEAKAAAABAAAAAgAAAAAQAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAAAAAAAAkAAAAAAAAACQAAAAAAAACZAAAAAAAAAJAAAAAAAAAJkAAAAAAAAAkAAAAAAAAA AAAAAAAAAAAAAAAAAAAzAAAAAAAAALsAAAAAAAAAu5kAAAAAAAC7CQAAAAAAAAAJmQAAAAAA AJkAAAAAAAAACQAAAAAAAACZAAAAAADvAAD/7wAA/88AAPvfAAD7nwAA978AAPA/AAD+fwAA 8n8AAPJ/AADwXwAA8l8AAP4fAAD8/wAA/v8AAPz/AAANCg0KDQrExMTExMTExMTExMTExMTE xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMQNCiBWWEJSQVNJTCBQUk9U RVNUTyBGQVogQUxHTyBSRUFMIFBFTE8gQlJBU0lMIExVTEEhISEhISANCsTExMTExMTExMTE xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExA0KAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0016_00003EA6.00000591-- From nitin.jain at citigroup.com Thu Dec 21 04:18:48 2006 From: nitin.jain at citigroup.com (Jain, Nitin [CPB]) Date: Wed, 20 Dec 2006 12:18:48 -0500 Subject: SFTP Message-ID: <2D907CA72B0F4F4696B87BD0FA1545D8054DEF98@EXNJMB50.nam.nsroot.net> Where do I need to specify the password in SFTP program to run it in an non-interactive mode. From miklos at szeredi.hu Thu Dec 21 03:14:37 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Wed, 20 Dec 2006 17:14:37 +0100 Subject: Nagle & delayed ACK strike again Message-ID: This time the problem is that the ssh server only sets TCP_NODELAY for interactive (tty) sessions or if X11 forwarding is enabled. Neither of which are true for the use of the sftp subsystem. This hurts upload performance for sftp/sshfs. I'm not sure why this hasn't cropped up earlier. Were there any TCP_NODELAY related changes in the sshd code recently? Is there a reason not to enable NODELAY unconditionally? Any reason why the server end is different from the client (where NODELAY is now uncoditionally enabled) in this respect? Thanks, Miklos From rick.jones2 at hp.com Thu Dec 21 08:58:20 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Wed, 20 Dec 2006 13:58:20 -0800 Subject: Nagle & delayed ACK strike again In-Reply-To: References: Message-ID: <4589B1FC.8070709@hp.com> Miklos Szeredi wrote: > This time the problem is that the ssh server only sets TCP_NODELAY for > interactive (tty) sessions or if X11 forwarding is enabled. Neither > of which are true for the use of the sftp subsystem. This hurts > upload performance for sftp/sshfs. > > I'm not sure why this hasn't cropped up earlier. Were there any > TCP_NODELAY related changes in the sshd code recently? > > Is there a reason not to enable NODELAY unconditionally? Any reason > why the server end is different from the client (where NODELAY is now > uncoditionally enabled) in this respect? I suspect that past discussions might be interesting reads - should be an an archive somewhere I suspect. My personal stance is that 99 times out of ten, if an end-user application speeds-up when it sets TCP_NODELAY, it implies the end-user application is broken and sending "logically associated" data in separate send calls. Now, if something is simply acting as a pipe, and passing along what it is given, then the above is not my opinion. But then, when something is acting as a pipe, it isn't what I would call the "end-user application" - it is part of the plumbing in the middle. rick jones From miklos at szeredi.hu Thu Dec 21 10:31:59 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 21 Dec 2006 00:31:59 +0100 Subject: Nagle & delayed ACK strike again In-Reply-To: <4589B1FC.8070709@hp.com> (message from Rick Jones on Wed, 20 Dec 2006 13:58:20 -0800) References: <4589B1FC.8070709@hp.com> Message-ID: > > This time the problem is that the ssh server only sets TCP_NODELAY for > > interactive (tty) sessions or if X11 forwarding is enabled. Neither > > of which are true for the use of the sftp subsystem. This hurts > > upload performance for sftp/sshfs. > > > > I'm not sure why this hasn't cropped up earlier. Were there any > > TCP_NODELAY related changes in the sshd code recently? > > > > Is there a reason not to enable NODELAY unconditionally? Any reason > > why the server end is different from the client (where NODELAY is now > > uncoditionally enabled) in this respect? > > I suspect that past discussions might be interesting reads - should be > an an archive somewhere I suspect. > > My personal stance is that 99 times out of ten, if an end-user > application speeds-up when it sets TCP_NODELAY, it implies the end-user > application is broken and sending "logically associated" data in > separate send calls. You tell me, is X protocol broken? Is SFTP broken? I don't think SFTP more broken than any other network fs protocol. The slowdown happens with a stream of WRITE requests and replies. If the requests weren't acknowledged, there wouldn't be any trouble, but acknowledgements do make sense for synchronous operation. You could probably design a protocol that weren't prone to this sort of problem, but likely that would make it more complex. Miklos From stuge-openssh-unix-dev at cdy.org Fri Dec 22 04:46:53 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 21 Dec 2006 18:46:53 +0100 Subject: SFTP In-Reply-To: <2D907CA72B0F4F4696B87BD0FA1545D8054DEF98@EXNJMB50.nam.nsroot.net> References: <2D907CA72B0F4F4696B87BD0FA1545D8054DEF98@EXNJMB50.nam.nsroot.net> Message-ID: <20061221174653.5456.qmail@cdy.org> Hi, On Wed, Dec 20, 2006 at 12:18:48PM -0500, Jain, Nitin [CPB] wrote: > Where do I need to specify the password in SFTP program to run it > in an non-interactive mode. sftp doesn't support that AFAIK. You could do an ugly hack with expect, or better yet use a private key and/or SSH agent to do automated authentication. //Peter From rick.jones2 at hp.com Fri Dec 22 06:01:44 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 21 Dec 2006 11:01:44 -0800 Subject: Nagle & delayed ACK strike again In-Reply-To: References: <4589B1FC.8070709@hp.com> Message-ID: <458ADA18.4060300@hp.com> >>My personal stance is that 99 times out of ten, if an end-user >>application speeds-up when it sets TCP_NODELAY, it implies the end-user >>application is broken and sending "logically associated" data in >>separate send calls. > > > You tell me, is X protocol broken? Likely not - the discrete mouse events which are usually cited as the reason X needs TCP_NODLEAY are not logically associated. Hence that is the 100th situation out of 10 rather then the 99. > Is SFTP broken? Depends - is it writing logically associated data to the connection in more than one send call? > I don't think > SFTP more broken than any other network fs protocol. The slowdown > happens with a stream of WRITE requests and replies. If the requests > weren't acknowledged, there wouldn't be any trouble, but > acknowledgements do make sense for synchronous operation. Do you have some system call traces and/or packet traces we could look at? If the write requests and replies are each single send call they probably qualify as the "X exception" rick jones From miklos at szeredi.hu Fri Dec 22 06:30:45 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 21 Dec 2006 20:30:45 +0100 Subject: Nagle & delayed ACK strike again In-Reply-To: <458ADA18.4060300@hp.com> (message from Rick Jones on Thu, 21 Dec 2006 11:01:44 -0800) References: <4589B1FC.8070709@hp.com> <458ADA18.4060300@hp.com> Message-ID: > >>My personal stance is that 99 times out of ten, if an end-user > >>application speeds-up when it sets TCP_NODELAY, it implies the end-user > >>application is broken and sending "logically associated" data in > >>separate send calls. > > > > > > You tell me, is X protocol broken? > > Likely not - the discrete mouse events which are usually cited as the > reason X needs TCP_NODLEAY are not logically associated. Hence that is > the 100th situation out of 10 rather then the 99. > > > Is SFTP broken? > > Depends - is it writing logically associated data to the connection in > more than one send call? No. They are logically separate calls. > > I don't think > > SFTP more broken than any other network fs protocol. The slowdown > > happens with a stream of WRITE requests and replies. If the requests > > weren't acknowledged, there wouldn't be any trouble, but > > acknowledgements do make sense for synchronous operation. > > Do you have some system call traces and/or packet traces we could look > at? If the write requests and replies are each single send call they > probably qualify as the "X exception" Yes this is the case. It's the symmetric counterpart of a READ message pair, where the request is small and the reply is large. In that case the client needed TCP_NODELAY to solve the delayed ACK interaction problem. With the WRITE is the opposite, the request is large and the reply is small, and now TCP_NODELAY is needed on the server. In both cases the request and the reply are sent to the socket with a single write() call. To me it still looks like the use of Nagle is the exception, it has already been turned off in the server for - interactive sessions - X11 forwarding and it will need to be turned off for - SFTP transport - IP tunnelling - ??? Is there any transported protocol where Nagle does make sense? Miklos From rick.jones2 at hp.com Fri Dec 22 09:42:37 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 21 Dec 2006 14:42:37 -0800 Subject: Nagle & delayed ACK strike again In-Reply-To: References: <4589B1FC.8070709@hp.com> <458ADA18.4060300@hp.com> Message-ID: <458B0DDD.8020806@hp.com> Miklos Szeredi wrote: >>>>My personal stance is that 99 times out of ten, if an end-user >>>>application speeds-up when it sets TCP_NODELAY, it implies the end-user >>>>application is broken and sending "logically associated" data in >>>>separate send calls. >>> >>> >>>You tell me, is X protocol broken? >> >>Likely not - the discrete mouse events which are usually cited as the >>reason X needs TCP_NODLEAY are not logically associated. Hence that is >>the 100th situation out of 10 rather then the 99. >> >> >>>Is SFTP broken? >> >>Depends - is it writing logically associated data to the connection in >>more than one send call? > > > No. They are logically separate calls. > > >>>I don't think >>>SFTP more broken than any other network fs protocol. The slowdown >>>happens with a stream of WRITE requests and replies. If the requests >>>weren't acknowledged, there wouldn't be any trouble, but >>>acknowledgements do make sense for synchronous operation. >> >>Do you have some system call traces and/or packet traces we could look >>at? If the write requests and replies are each single send call they >>probably qualify as the "X exception" > > > Yes this is the case. It's the symmetric counterpart of a READ > message pair, where the request is small and the reply is large. In > that case the client needed TCP_NODELAY to solve the delayed ACK > interaction problem. > > With the WRITE is the opposite, the request is large and the reply is > small, and now TCP_NODELAY is needed on the server. > > In both cases the request and the reply are sent to the socket with a > single write() call. > > To me it still looks like the use of Nagle is the exception, it has > already been turned off in the server for > > - interactive sessions For at least some interactive sessions. In the telnet space at least, there is this constant back and forth happening bewteen wanting keystrokes to be nice and uniform, and not overwhelming slot terminal devices (eg barcode scanners) when applications on the server dump a bunch of stuff down stdio. > - X11 forwarding > > and it will need to be turned off for > > - SFTP transport > > - IP tunnelling > > - ??? > > Is there any transported protocol where Nagle does make sense? Regular FTP is one, anything unidirectional. It also depends on what one is trying to optimize. If one is only interested in optimizing time, Nagle may not be the thing. However, Nagle can optimize the ratio of data to data+headers and it can optimize the quanity of CPU consumed per unit of data transferred. Some netperf data for the unidirectional case, between a system in Palo Alto and one in Cupertino, sending-side CPU utilization included, similar things can happen to receive-side CPU: TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.56.217) port 0 AF_INET Recv Send Send Utilization Service Demand SocketSocket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB 131072 219136 512 10.10 74.59 8.78 -1.00 9.648 -1.000 raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -- -m 512 -s 128K -S 128K -D TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB 131072 219136 512 10.02 69.21 20.56 -1.00 24.335 -1.000 The multiple concurrent request/response case is more nuanced and difficule to make. Basically, it is a race between how many small requests (or responses) will be made at one time, the RTT between the systems, the standalone ACK timer on the receiver, and the service time on the receiver. Here is some data with netperf TCP_RR between those two systems: raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR -- -r 128,2048 -b 3 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : first burst 3 Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr 16384 87380 128 2048 10.00 1106.42 4.74 -1.00 42.852 -1.000 32768 32768 raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR -- -r 128,2048 -b 3 -D TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay : first burst 3 Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr 16384 87380 128 2048 10.01 2145.98 10.49 -1.00 48.875 -1.000 32768 32768 Now, setting TCP_NODELAY did indeed produce a big jump in transactions per second. Notice though how it also resulted in a 14% increase in CPU utilization per transaction. Clearly the lunch was not free. The percentage difference in transactions per second will converge the larger the number of outstanding transactions. Taking the settings from above, where the first column is the size of the burst in netperf, the second is without TCP_NODELAY set, the third with: raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 128,2048 -b $i; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 128,2048 -b $i -D`; done 3 1186.40 2218.63 6 1952.53 3695.64 9 2574.49 4833.47 12 3194.71 4856.63 15 3388.54 4784.26 18 4215.70 5099.52 21 4645.97 5170.89 24 4918.16 5336.79 27 4927.71 5448.78 If we increase the request size to 256 bytes, and the response to 8192 (In all honesty I don't know what sizes sftp might use so I'm making wild guesses) we can see the convergence happen much sooner - it takes fewer of the 8192 byte responses to take the TCP connection to the bandwidth delay product of the link: raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 256,8192 -b $i -s 128K -S 128K; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 256,8192 -s 128K -S 128K -b $i -D`; done 3 895.18 1279.38 6 1309.11 1405.38 9 1395.30 1325.44 12 1256.75 1422.01 15 1412.39 1413.64 18 1400.04 1419.76 21 1415.62 1422.79 24 1419.56 1420.10 27 1422.43 1379.72 rick jones From miklos at szeredi.hu Fri Dec 22 10:14:40 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Fri, 22 Dec 2006 00:14:40 +0100 Subject: Nagle & delayed ACK strike again In-Reply-To: <458B0DDD.8020806@hp.com> (message from Rick Jones on Thu, 21 Dec 2006 14:42:37 -0800) References: <4589B1FC.8070709@hp.com> <458ADA18.4060300@hp.com> <458B0DDD.8020806@hp.com> Message-ID: > > To me it still looks like the use of Nagle is the exception, it has > > already been turned off in the server for > > > > - interactive sessions > > For at least some interactive sessions. In the telnet space at least, > there is this constant back and forth happening bewteen wanting > keystrokes to be nice and uniform, and not overwhelming slot terminal > devices (eg barcode scanners) when applications on the server dump a > bunch of stuff down stdio. For ssh this is unconditional. I've suggested adding NoDelay/ NoNoDelay options, but somebody on this list vetoed that. > > - X11 forwarding > > > > and it will need to be turned off for > > > > - SFTP transport > > > > - IP tunnelling > > > > - ??? > > > > Is there any transported protocol where Nagle does make sense? > > Regular FTP is one, anything unidirectional. Nagle doesn't help FTP or HTTP does it? Anything that just pushes a big chunk of data will automatically end up with big packets. So other than the disputed interactive session, Nagle doesn't seem to have any positive effects. > It also depends on what one is trying to optimize. If one is only > interested in optimizing time, Nagle may not be the thing. However, > Nagle can optimize the ratio of data to data+headers and it can optimize > the quanity of CPU consumed per unit of data transferred. For a filesystem protocol obviously latency (and hence throughput) is the most important factor. > Some netperf data for the unidirectional case, between a system in Palo > Alto and one in Cupertino, sending-side CPU utilization included, > similar things can happen to receive-side CPU: > > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET > Recv Send Send Utilization Service Demand > SocketSocket Message Elapsed Send Recv Send Recv > Size Size Size Time Throughput local remote local remote > bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB > > 131072 219136 512 10.10 74.59 8.78 -1.00 9.648 -1.000 > > raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -- -m 512 > -s 128K -S 128K -D > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay > Recv Send Send Utilization Service Demand > Socket Socket Message Elapsed Send Recv Send Recv > Size Size Size Time Throughput local remote local remote > bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB > > 131072 219136 512 10.02 69.21 20.56 -1.00 24.335 -1.000 > > The multiple concurrent request/response case is more nuanced and > difficule to make. Basically, it is a race between how many small > requests (or responses) will be made at one time, the RTT between the > systems, the standalone ACK timer on the receiver, and the service time > on the receiver. > > Here is some data with netperf TCP_RR between those two systems: > > raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR > -- -r 128,2048 -b 3 > TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : first burst 3 > Local /Remote > Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem > Send Recv Size Size Time Rate local remote local remote > bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr > > 16384 87380 128 2048 10.00 1106.42 4.74 -1.00 42.852 -1.000 > 32768 32768 > raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR > -- -r 128,2048 -b 3 -D > TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay : first burst 3 > Local /Remote > Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem > Send Recv Size Size Time Rate local remote local remote > bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr > > 16384 87380 128 2048 10.01 2145.98 10.49 -1.00 48.875 -1.000 > 32768 32768 > > > Now, setting TCP_NODELAY did indeed produce a big jump in transactions > per second. Notice though how it also resulted in a 14% increase in CPU > utilization per transaction. Clearly the lunch was not free. > > The percentage difference in transactions per second will converge the > larger the number of outstanding transactions. Taking the settings from > above, where the first column is the size of the burst in netperf, the > second is without TCP_NODELAY set, the third with: > > raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i > `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 128,2048 > -b $i; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r > 128,2048 -b $i -D`; done > 3 1186.40 2218.63 > 6 1952.53 3695.64 > 9 2574.49 4833.47 > 12 3194.71 4856.63 > 15 3388.54 4784.26 > 18 4215.70 5099.52 > 21 4645.97 5170.89 > 24 4918.16 5336.79 > 27 4927.71 5448.78 > > If we increase the request size to 256 bytes, and the response to 8192 > (In all honesty I don't know what sizes sftp might use so I'm making > wild guesses) we can see the convergence happen much sooner - it takes > fewer of the 8192 byte responses to take the TCP connection to the > bandwidth delay product of the link: > > raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i > `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 256,8192 > -b $i -s 128K -S 128K; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P > 0 -v 0 -- -r 256,8192 -s 128K -S 128K -b $i -D`; done > 3 895.18 1279.38 > 6 1309.11 1405.38 > 9 1395.30 1325.44 > 12 1256.75 1422.01 > 15 1412.39 1413.64 > 18 1400.04 1419.76 > 21 1415.62 1422.79 > 24 1419.56 1420.10 > 27 1422.43 1379.72 In SFTP the WRIYR request/reply sizes are more like 64kB/32B, and the outstanding transactions are as many as the socket buffers will bear. The slowdown is clearly due to 50ms outages from delayed ACK, which is totally broken, the network is just sitting there idle for no good reason whatsoever. I can make new traces, but I guess they would be very similar to the ones I sent last time for the SFTP download case. Miklos From rapier at psc.edu Fri Dec 22 12:51:49 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 21 Dec 2006 20:51:49 -0500 Subject: Nagle & delayed ACK strike again In-Reply-To: References: <4589B1FC.8070709@hp.com> <458ADA18.4060300@hp.com> <458B0DDD.8020806@hp.com> Message-ID: <458B3A35.4030104@psc.edu> I'm assuming that the network in question has a 1500B MTU. Does anything change if the MTU is increased to 9k? Miklos Szeredi wrote: >>> To me it still looks like the use of Nagle is the exception, it has >>> already been turned off in the server for >>> >>> - interactive sessions >> For at least some interactive sessions. In the telnet space at least, >> there is this constant back and forth happening bewteen wanting >> keystrokes to be nice and uniform, and not overwhelming slot terminal >> devices (eg barcode scanners) when applications on the server dump a >> bunch of stuff down stdio. > > For ssh this is unconditional. I've suggested adding NoDelay/ > NoNoDelay options, but somebody on this list vetoed that. > >>> - X11 forwarding >>> >>> and it will need to be turned off for >>> >>> - SFTP transport >>> >>> - IP tunnelling >>> >>> - ??? >>> >>> Is there any transported protocol where Nagle does make sense? >> Regular FTP is one, anything unidirectional. > > Nagle doesn't help FTP or HTTP does it? Anything that just pushes a > big chunk of data will automatically end up with big packets. > > So other than the disputed interactive session, Nagle doesn't seem to > have any positive effects. > >> It also depends on what one is trying to optimize. If one is only >> interested in optimizing time, Nagle may not be the thing. However, >> Nagle can optimize the ratio of data to data+headers and it can optimize >> the quanity of CPU consumed per unit of data transferred. > > For a filesystem protocol obviously latency (and hence throughput) is > the most important factor. > >> Some netperf data for the unidirectional case, between a system in Palo >> Alto and one in Cupertino, sending-side CPU utilization included, >> similar things can happen to receive-side CPU: >> >> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to >> tardy.cup.hp.com (15.244.56.217) port 0 AF_INET >> Recv Send Send Utilization Service Demand >> SocketSocket Message Elapsed Send Recv Send Recv >> Size Size Size Time Throughput local remote local remote >> bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB >> >> 131072 219136 512 10.10 74.59 8.78 -1.00 9.648 -1.000 >> >> raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -- -m 512 >> -s 128K -S 128K -D >> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to >> tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay >> Recv Send Send Utilization Service Demand >> Socket Socket Message Elapsed Send Recv Send Recv >> Size Size Size Time Throughput local remote local remote >> bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB >> >> 131072 219136 512 10.02 69.21 20.56 -1.00 24.335 -1.000 >> >> The multiple concurrent request/response case is more nuanced and >> difficule to make. Basically, it is a race between how many small >> requests (or responses) will be made at one time, the RTT between the >> systems, the standalone ACK timer on the receiver, and the service time >> on the receiver. >> >> Here is some data with netperf TCP_RR between those two systems: >> >> raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR >> -- -r 128,2048 -b 3 >> TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to >> tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : first burst 3 >> Local /Remote >> Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem >> Send Recv Size Size Time Rate local remote local remote >> bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr >> >> 16384 87380 128 2048 10.00 1106.42 4.74 -1.00 42.852 -1.000 >> 32768 32768 >> raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR >> -- -r 128,2048 -b 3 -D >> TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to >> tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay : first burst 3 >> Local /Remote >> Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem >> Send Recv Size Size Time Rate local remote local remote >> bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr >> >> 16384 87380 128 2048 10.01 2145.98 10.49 -1.00 48.875 -1.000 >> 32768 32768 >> >> >> Now, setting TCP_NODELAY did indeed produce a big jump in transactions >> per second. Notice though how it also resulted in a 14% increase in CPU >> utilization per transaction. Clearly the lunch was not free. >> >> The percentage difference in transactions per second will converge the >> larger the number of outstanding transactions. Taking the settings from >> above, where the first column is the size of the burst in netperf, the >> second is without TCP_NODELAY set, the third with: >> >> raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i >> `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 128,2048 >> -b $i; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r >> 128,2048 -b $i -D`; done >> 3 1186.40 2218.63 >> 6 1952.53 3695.64 >> 9 2574.49 4833.47 >> 12 3194.71 4856.63 >> 15 3388.54 4784.26 >> 18 4215.70 5099.52 >> 21 4645.97 5170.89 >> 24 4918.16 5336.79 >> 27 4927.71 5448.78 >> >> If we increase the request size to 256 bytes, and the response to 8192 >> (In all honesty I don't know what sizes sftp might use so I'm making >> wild guesses) we can see the convergence happen much sooner - it takes >> fewer of the 8192 byte responses to take the TCP connection to the >> bandwidth delay product of the link: >> >> raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i >> `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 256,8192 >> -b $i -s 128K -S 128K; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P >> 0 -v 0 -- -r 256,8192 -s 128K -S 128K -b $i -D`; done >> 3 895.18 1279.38 >> 6 1309.11 1405.38 >> 9 1395.30 1325.44 >> 12 1256.75 1422.01 >> 15 1412.39 1413.64 >> 18 1400.04 1419.76 >> 21 1415.62 1422.79 >> 24 1419.56 1420.10 >> 27 1422.43 1379.72 > > In SFTP the WRIYR request/reply sizes are more like 64kB/32B, and the > outstanding transactions are as many as the socket buffers will bear. > > The slowdown is clearly due to 50ms outages from delayed ACK, which is > totally broken, the network is just sitting there idle for no good > reason whatsoever. > > I can make new traces, but I guess they would be very similar to the > ones I sent last time for the SFTP download case. > > Miklos > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rapier at psc.edu Fri Dec 22 13:00:13 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 21 Dec 2006 21:00:13 -0500 Subject: Nagle & delayed ACK strike again In-Reply-To: <458B3A35.4030104@psc.edu> References: <4589B1FC.8070709@hp.com> <458ADA18.4060300@hp.com> <458B0DDD.8020806@hp.com> <458B3A35.4030104@psc.edu> Message-ID: <458B3C2D.2020200@psc.edu> Chris Rapier wrote: > I'm assuming that the network in question has a 1500B MTU. Does anything > change if the MTU is increased to 9k? Never mind, answered my own question. From djm at mindrot.org Fri Dec 22 14:20:12 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Dec 2006 14:20:12 +1100 (EST) Subject: Nagle & delayed ACK strike again In-Reply-To: References: <4589B1FC.8070709@hp.com> <458ADA18.4060300@hp.com> <458B0DDD.8020806@hp.com> Message-ID: sorry to interrupt your argument: revision 1.120 date: 2006/03/15 01:05:22; author: djm; state: Exp; lines: +2 -3 - dtucker at cvs.openbsd.org 2006/03/13 08:33:00 [packet.c] Set TCP_NODELAY for all connections not just "interactive" ones. Fixes poor performance and protocol stalls under some network conditions (mindrot bugs #556 and #981). Patch originally from markus@, ok djm@ is in OpenSSH from 4.4 onwards On Fri, 22 Dec 2006, Miklos Szeredi wrote: > > > To me it still looks like the use of Nagle is the exception, it has > > > already been turned off in the server for > > > > > > - interactive sessions > > > > For at least some interactive sessions. In the telnet space at least, > > there is this constant back and forth happening bewteen wanting > > keystrokes to be nice and uniform, and not overwhelming slot terminal > > devices (eg barcode scanners) when applications on the server dump a > > bunch of stuff down stdio. > > For ssh this is unconditional. I've suggested adding NoDelay/ > NoNoDelay options, but somebody on this list vetoed that. > > > > - X11 forwarding > > > > > > and it will need to be turned off for > > > > > > - SFTP transport > > > > > > - IP tunnelling > > > > > > - ??? > > > > > > Is there any transported protocol where Nagle does make sense? > > > > Regular FTP is one, anything unidirectional. > > Nagle doesn't help FTP or HTTP does it? Anything that just pushes a > big chunk of data will automatically end up with big packets. > > So other than the disputed interactive session, Nagle doesn't seem to > have any positive effects. > > > It also depends on what one is trying to optimize. If one is only > > interested in optimizing time, Nagle may not be the thing. However, > > Nagle can optimize the ratio of data to data+headers and it can optimize > > the quanity of CPU consumed per unit of data transferred. > > For a filesystem protocol obviously latency (and hence throughput) is > the most important factor. > > > Some netperf data for the unidirectional case, between a system in Palo > > Alto and one in Cupertino, sending-side CPU utilization included, > > similar things can happen to receive-side CPU: > > > > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET > > Recv Send Send Utilization Service Demand > > SocketSocket Message Elapsed Send Recv Send Recv > > Size Size Size Time Throughput local remote local remote > > bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB > > > > 131072 219136 512 10.10 74.59 8.78 -1.00 9.648 -1.000 > > > > raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -- -m 512 > > -s 128K -S 128K -D > > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay > > Recv Send Send Utilization Service Demand > > Socket Socket Message Elapsed Send Recv Send Recv > > Size Size Size Time Throughput local remote local remote > > bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB > > > > 131072 219136 512 10.02 69.21 20.56 -1.00 24.335 -1.000 > > > > The multiple concurrent request/response case is more nuanced and > > difficule to make. Basically, it is a race between how many small > > requests (or responses) will be made at one time, the RTT between the > > systems, the standalone ACK timer on the receiver, and the service time > > on the receiver. > > > > Here is some data with netperf TCP_RR between those two systems: > > > > raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR > > -- -r 128,2048 -b 3 > > TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : first burst 3 > > Local /Remote > > Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem > > Send Recv Size Size Time Rate local remote local remote > > bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr > > > > 16384 87380 128 2048 10.00 1106.42 4.74 -1.00 42.852 -1.000 > > 32768 32768 > > raj at tardy:~/netperf2_work$ src/netperf -H tardy.cup.hp.com -c -t TCP_RR > > -- -r 128,2048 -b 3 -D > > TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to > > tardy.cup.hp.com (15.244.56.217) port 0 AF_INET : nodelay : first burst 3 > > Local /Remote > > Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem > > Send Recv Size Size Time Rate local remote local remote > > bytes bytes bytes bytes secs. per sec % S % U us/Tr us/Tr > > > > 16384 87380 128 2048 10.01 2145.98 10.49 -1.00 48.875 -1.000 > > 32768 32768 > > > > > > Now, setting TCP_NODELAY did indeed produce a big jump in transactions > > per second. Notice though how it also resulted in a 14% increase in CPU > > utilization per transaction. Clearly the lunch was not free. > > > > The percentage difference in transactions per second will converge the > > larger the number of outstanding transactions. Taking the settings from > > above, where the first column is the size of the burst in netperf, the > > second is without TCP_NODELAY set, the third with: > > > > raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i > > `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 128,2048 > > -b $i; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r > > 128,2048 -b $i -D`; done > > 3 1186.40 2218.63 > > 6 1952.53 3695.64 > > 9 2574.49 4833.47 > > 12 3194.71 4856.63 > > 15 3388.54 4784.26 > > 18 4215.70 5099.52 > > 21 4645.97 5170.89 > > 24 4918.16 5336.79 > > 27 4927.71 5448.78 > > > > If we increase the request size to 256 bytes, and the response to 8192 > > (In all honesty I don't know what sizes sftp might use so I'm making > > wild guesses) we can see the convergence happen much sooner - it takes > > fewer of the 8192 byte responses to take the TCP connection to the > > bandwidth delay product of the link: > > > > raj at tardy:~/netperf2_work$ for i in 3 6 9 12 15 18 21 24 27; do echo $i > > `src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P 0 -v 0 -- -r 256,8192 > > -b $i -s 128K -S 128K; src/netperf -H tardy.cup.hp.com -t TCP_RR -l 4 -P > > 0 -v 0 -- -r 256,8192 -s 128K -S 128K -b $i -D`; done > > 3 895.18 1279.38 > > 6 1309.11 1405.38 > > 9 1395.30 1325.44 > > 12 1256.75 1422.01 > > 15 1412.39 1413.64 > > 18 1400.04 1419.76 > > 21 1415.62 1422.79 > > 24 1419.56 1420.10 > > 27 1422.43 1379.72 > > In SFTP the WRIYR request/reply sizes are more like 64kB/32B, and the > outstanding transactions are as many as the socket buffers will bear. > > The slowdown is clearly due to 50ms outages from delayed ACK, which is > totally broken, the network is just sitting there idle for no good > reason whatsoever. > > I can make new traces, but I guess they would be very similar to the > ones I sent last time for the SFTP download case. > > Miklos > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >