[PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[Nami]

From: nami <nami.li@atheros.com>


Signed-off-by: Nami <nami.li@atheros.com>
---
 glib/obex-lowlevel.c          |    2 +-
 include/openobex/obex.h       |    2 +-
 include/openobex/obex_const.h |    5 +++++
 lib/obex.c                    |    3 ++-
 lib/obex_main.c               |    5 ++++-
 lib/obex_transport.h          |    1 +
 6 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/glib/obex-lowlevel.c b/glib/obex-lowlevel.c
index 65172fc..660fc37 100644
--- a/glib/obex-lowlevel.c
+++ b/glib/obex-lowlevel.c
@@ -496,7 +496,7 @@ obex_t *obex_open(int fd, obex_callback_t *callback, void *data)

 	OBEX_SetTransportMTU(handle, sizeof(context->buf), sizeof(context->buf));

-	if (FdOBEX_TransportSetup(handle, fd, fd, 0) < 0) {
+	if (FdOBEX_TransportSetup(handle, fd, fd, 0, OBEX_MT_STREAM) < 0) {
 		OBEX_Cleanup(handle);
 		return NULL;
 	}
diff --git a/include/openobex/obex.h b/include/openobex/obex.h
index f948113..0d7afec 100644
--- a/include/openobex/obex.h
+++ b/include/openobex/obex.h
@@ -147,7 +147,7 @@ OPENOBEX_SYMBOL(int) BtOBEX_TransportConnect(obex_t *self, bt_addr_t *src, bt_ad
 /*
  * OBEX File API
  */
-OPENOBEX_SYMBOL(int) FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu);
+OPENOBEX_SYMBOL(int) FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu, int fmt);

 /*
  * OBEX interface discovery API
diff --git a/include/openobex/obex_const.h b/include/openobex/obex_const.h
index cb7afeb..4a0a7e9 100644
--- a/include/openobex/obex_const.h
+++ b/include/openobex/obex_const.h
@@ -302,6 +302,11 @@ enum obex_rsp_mode {
   OBEX_RSP_MODE_SINGLE = 1, /**< single response mode (SRM) */
 };

+enum obex_transport_format{
+	 OBEX_MT_STREAM ,
+	 OBEX_MT_SEQPACKET
+};
+
 /* Min, Max and default transport MTU */
 #define OBEX_DEFAULT_MTU	1024
 #define OBEX_MINIMUM_MTU	255
diff --git a/lib/obex.c b/lib/obex.c
index 5ca14a2..06c890a 100644
--- a/lib/obex.c
+++ b/lib/obex.c
@@ -1118,7 +1118,7 @@ int CALLAPI BtOBEX_TransportConnect(obex_t *self, bdaddr_t *src,
 	\return -1 or negative error code on error
  */
 LIB_SYMBOL
-int CALLAPI FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu)
+int CALLAPI FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu, int fmt)
 {
 	DEBUG(4, "\n");

@@ -1131,6 +1131,7 @@ int CALLAPI FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu)
 	self->trans.fd = rfd;
 	self->trans.data.fd.writefd = wfd;
 	self->trans.mtu = mtu ? mtu : self->mtu_tx_max;
+	self->trans.fmt = fmt;
 	return obex_transport_connect_request(self);
 }

diff --git a/lib/obex_main.c b/lib/obex_main.c
index 387f271..8730419 100644
--- a/lib/obex_main.c
+++ b/lib/obex_main.c
@@ -301,7 +301,10 @@ int obex_data_indication(obex_t *self)

 	/* First we need 3 bytes to be able to know how much data to read */
 	if (msg->data_size < sizeof(*hdr))  {
-		actual = obex_transport_read(self, sizeof(*hdr)-msg->data_size);
+		if(self->trans.fmt == OBEX_MT_STREAM)
+			actual = obex_transport_read(self, sizeof(*hdr)-msg->data_size);
+		else
+			actual = obex_transport_read(self, self->mtu_rx);

 		DEBUG(4, "Got %d bytes\n", actual);

diff --git a/lib/obex_transport.h b/lib/obex_transport.h
index a39f563..e80a5cb 100644
--- a/lib/obex_transport.h
+++ b/lib/obex_transport.h
@@ -114,6 +114,7 @@ typedef struct obex_transport {

 	int connected;		/* Link connection state */
 	unsigned int mtu;	/* Tx MTU of the link */
+	enum obex_transport_format fmt;	/* Data transport foramt */

 } obex_transport_t;

--
1.7.1

Re: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[Marcel Holtmann]

Hi Nami,

> From: nami <nami.li@atheros.com>
> 
> 
> Signed-off-by: Nami <nami.li@atheros.com>

same as with the other one.

> ---
>  glib/obex-lowlevel.c          |    2 +-
>  include/openobex/obex.h       |    2 +-
>  include/openobex/obex_const.h |    5 +++++
>  lib/obex.c                    |    3 ++-
>  lib/obex_main.c               |    5 ++++-
>  lib/obex_transport.h          |    1 +
>  6 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/glib/obex-lowlevel.c b/glib/obex-lowlevel.c
> index 65172fc..660fc37 100644
> --- a/glib/obex-lowlevel.c
> +++ b/glib/obex-lowlevel.c
> @@ -496,7 +496,7 @@ obex_t *obex_open(int fd, obex_callback_t *callback, void *data)
> 
>  	OBEX_SetTransportMTU(handle, sizeof(context->buf), sizeof(context->buf));
> 
> -	if (FdOBEX_TransportSetup(handle, fd, fd, 0) < 0) {
> +	if (FdOBEX_TransportSetup(handle, fd, fd, 0, OBEX_MT_STREAM) < 0) {
>  		OBEX_Cleanup(handle);
>  		return NULL;
>  	}
> diff --git a/include/openobex/obex.h b/include/openobex/obex.h
> index f948113..0d7afec 100644
> --- a/include/openobex/obex.h
> +++ b/include/openobex/obex.h
> @@ -147,7 +147,7 @@ OPENOBEX_SYMBOL(int) BtOBEX_TransportConnect(obex_t *self, bt_addr_t *src, bt_ad
>  /*
>   * OBEX File API
>   */
> -OPENOBEX_SYMBOL(int) FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu);
> +OPENOBEX_SYMBOL(int) FdOBEX_TransportSetup(obex_t *self, int rfd, int wfd, int mtu, int fmt);

this is breaking public API.

>  /*
>   * OBEX interface discovery API
> diff --git a/include/openobex/obex_const.h b/include/openobex/obex_const.h
> index cb7afeb..4a0a7e9 100644
> --- a/include/openobex/obex_const.h
> +++ b/include/openobex/obex_const.h
> @@ -302,6 +302,11 @@ enum obex_rsp_mode {
>    OBEX_RSP_MODE_SINGLE = 1, /**< single response mode (SRM) */
>  };
> 
> +enum obex_transport_format{
> +	 OBEX_MT_STREAM ,
> +	 OBEX_MT_SEQPACKET
> +};
> +

And more important, I have no idea why are you doing this anyway. Even
with L2CAP this should run over SOCK_STREAM.

I assumed that OPP and FTP over L2CAP are requiring eL2CAP actually
which is re-presented as a stream.

Regards

Marcel

RE: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[tim.howes]

SGkgTWFyY2VsLA0KDQoNCj4gK2VudW0gb2JleF90cmFuc3BvcnRfZm9ybWF0ew0KPiArICAgICAg
T0JFWF9NVF9TVFJFQU0gLA0KPiArICAgICAgT0JFWF9NVF9TRVFQQUNLRVQNCj4gK307DQo+ICsN
Cj4gQW5kIG1vcmUgaW1wb3J0YW50LCBJIGhhdmUgbm8gaWRlYSB3aHkgYXJlIHlvdSBkb2luZyB0
aGlzIGFueXdheS4gRXZlbg0KPiB3aXRoIEwyQ0FQIHRoaXMgc2hvdWxkIHJ1biBvdmVyIFNPQ0tf
U1RSRUFNLg0KDQpJcyB0aGF0IHJlYWxseSBzbz8gIEkgZXhwZWN0IGV4cG9zaW5nIEwyQ0FQIEVS
VE0gYXMgYSBzdHJlYW0gY291bGQgYnJlYWsgcHJvdG9jb2xzIGFib3ZlIHRoYXQgZXhwZWN0IGRh
dGFncmFtLWJvdW5kYXJ5IHByZXNlcnZhdGlvbiAoZWcgUlRQKS4gIE9yIGNhbiBicmVhayBwcm90
b2NvbHMgdGhhdCBtYW5kYXRlIHRoYXQgb25seSBvbmUgaGlnaGVyLWxheWVyIHBhY2tldCBleGlz
dHMgaW4gZWFjaCBMMkNBUCBTRFUuICBGb3IgdGhlc2UgdGhlIHNvY2tldCBuZWVkcyB0byBiZSBw
YWNrZXQgYmFzZWQuDQoNClNvLCBteSBzdXJwcmlzZSBpcyB0aGF0IEVSVE0gaXMgZXhwb3NlZCBh
cyBTT0NLX1NUUkVBTS4gIFNvIEkgZG8gaGF2ZSBhbiBpZGVhIHdoeSB0aGUgcGF0Y2ggbWVudGlv
bnMgc2VxdWVuY2VkIHBhY2tldC4uLg0KDQo+IEkgYXNzdW1lZCB0aGF0IE9QUCBhbmQgRlRQIG92
ZXIgTDJDQVAgYXJlIHJlcXVpcmluZyBlTDJDQVAgYWN0dWFsbHkNCj4gd2hpY2ggaXMgcmUtcHJl
c2VudGVkIGFzIGEgc3RyZWFtLg0KDQpZZXMsIE9CRVggb3ZlciBMMkNBUCByZXF1aXJlcyBlbmhh
bmNlZCByZXRyYW5zbWlzc2lvbiBtb2RlLg0KDQpUaW0NCg0KVGhpcyBtZXNzYWdlIGlzIGZvciB0
aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCwg
cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgSWYgeW91IGhh
dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh
dGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSBvdGhlciB1c2Ugb2YgdGhlIGVtYWls
IGJ5IHlvdSBpcyBwcm9oaWJpdGVkLg0K

RE: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[piotr.zgorecki]

SGkgVGltLCBNYXJjZWwsDQoNCj4+ICtlbnVtIG9iZXhfdHJhbnNwb3J0X2Zvcm1hdHsNCj4+ICsg
ICAgIE9CRVhfTVRfU1RSRUFNICwNCj4+ICsgICAgIE9CRVhfTVRfU0VRUEFDS0VUDQo+PiArfTsN
Cj4+ICsNCj4+IEFuZCBtb3JlIGltcG9ydGFudCwgSSBoYXZlIG5vIGlkZWEgd2h5IGFyZSB5b3Ug
ZG9pbmcgdGhpcyBhbnl3YXkuIEV2ZW4NCj4+IHdpdGggTDJDQVAgdGhpcyBzaG91bGQgcnVuIG92
ZXIgU09DS19TVFJFQU0uDQo+DQo+SXMgdGhhdCByZWFsbHkgc28/ICBJIGV4cGVjdCBleHBvc2lu
ZyBMMkNBUCBFUlRNIGFzIGEgc3RyZWFtIGNvdWxkIGJyZWFrIHByb3RvY29scyBhYm92ZSB0aGF0
ID5leHBlY3QgZGF0YWdyYW0tYm91bmRhcnkgcHJlc2VydmF0aW9uIChlZyBSVFApLiAgT3IgY2Fu
IGJyZWFrIHByb3RvY29scyB0aGF0IG1hbmRhdGUgdGhhdCA+b25seSBvbmUgaGlnaGVyLWxheWVy
IHBhY2tldCBleGlzdHMgaW4gZWFjaCBMMkNBUCBTRFUuICBGb3IgdGhlc2UgdGhlIHNvY2tldCBu
ZWVkcyB0byBiZSA+cGFja2V0IGJhc2VkLg0KPg0KPlNvLCBteSBzdXJwcmlzZSBpcyB0aGF0IEVS
VE0gaXMgZXhwb3NlZCBhcyBTT0NLX1NUUkVBTS4gIFNvIEkgZG8gaGF2ZSBhbiBpZGVhIHdoeSB0
aGUgcGF0Y2ggPm1lbnRpb25zIHNlcXVlbmNlZCBwYWNrZXQuLi4NCj4NCj4+IEkgYXNzdW1lZCB0
aGF0IE9QUCBhbmQgRlRQIG92ZXIgTDJDQVAgYXJlIHJlcXVpcmluZyBlTDJDQVAgYWN0dWFsbHkN
Cj4+IHdoaWNoIGlzIHJlLXByZXNlbnRlZCBhcyBhIHN0cmVhbS4NCj4NCj5ZZXMsIE9CRVggb3Zl
ciBMMkNBUCByZXF1aXJlcyBlbmhhbmNlZCByZXRyYW5zbWlzc2lvbiBtb2RlLg0KDQpGcm9tIHRo
ZSBDb3JlIFNwZWNpZmljYXRpb24sIFZvbC4gMywgUGFydCBBLCBQdC4gNy4zIEVuY2Fwc3VsYXRp
b24gb2YgU0RVczoNCiJJdCBpcyBhc3N1bWVkIHRoYXQgU0RVIGJvdW5kYXJpZXMgc2hhbGwgYmUg
cHJlc2VydmVkIGJldHdlZW4gcGVlciB1cHBlciBsYXllciBlbnRpdGllcy4iDQoNClNEVSBpcyBi
eSBkZWZpbml0aW9uIGFuIGFic3RyYWN0aW9uIGV4cG9zZWQgdG8gdGhlIHVwcGVyIGxheWVyLiBU
aGlzIGFzc3VtcHRpb24gcGVybWVhdGVzIGFsbCBvZiBCbHVldG9vdGggYW5kIGJyZWFraW5nIGl0
IGNhbiBoYXZlIGRpcmUgY29uc2VxdWVuY2VzIGJvdGggZm9yIHByb2ZpbGVzIGFzc3VtaW5nIHRo
ZWlyIG1lc3NhZ2VzIG1hcCAxOjEgdG8gU0RVcy4NCg0KQ2hlZXJzLA0KUGlvdHINCg0KVGhpcyBt
ZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5IGNvbnRh
aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0
aW9uLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSBvdGhlciB1
c2Ugb2YgdGhlIGVtYWlsIGJ5IHlvdSBpcyBwcm9oaWJpdGVkLg0K

Re: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[Piotr Zgórecki]

Tim, Marcel,

> > +enum obex_transport_format{
> > +      OBEX_MT_STREAM ,
> > +      OBEX_MT_SEQPACKET
> > +};
> > +
> > And more important, I have no idea why are you doing this anyway. Even
> > with L2CAP this should run over SOCK_STREAM.
>
> Is that really so?  I expect exposing L2CAP ERTM as a stream could break protocols above that expect datagram-boundary preservation (eg RTP).  Or can break protocols that mandate that only one higher-layer packet exists in each L2CAP SDU.  For these the socket needs to be packet based.
>
> So, my surprise is that ERTM is exposed as SOCK_STREAM.  So I do have an idea why the patch mentions sequenced packet...

>From the Core Specification, Vol. 3, Part A, Pt. 7.3 Encapsulation of SDUs:
"It is assumed that SDU boundaries shall be preserved between peer
upper layer entities."

SDU is by definition an abstraction exposed to the upper layer. This
assumption permeates all of Bluetooth and breaking it can have dire
consequences for profiles assuming their messages map 1:1 to SDUs.
That's obviously assuming that using SOCK_STREAM breaks this
assumption :)

Cheers,
Piotr

RE: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[Marcel Holtmann]

Hi Tim,

> > +enum obex_transport_format{
> > +      OBEX_MT_STREAM ,
> > +      OBEX_MT_SEQPACKET
> > +};
> > +
> > And more important, I have no idea why are you doing this anyway. Even
> > with L2CAP this should run over SOCK_STREAM.
> 
> Is that really so?  I expect exposing L2CAP ERTM as a stream could break protocols above that expect datagram-boundary preservation (eg RTP).  Or can break protocols that mandate that only one higher-layer packet exists in each L2CAP SDU.  For these the socket needs to be packet based.
> 
> So, my surprise is that ERTM is exposed as SOCK_STREAM.  So I do have an idea why the patch mentions sequenced packet...

you can do both for ERTM actually. You can create SOCK_SEQPACKET and
have it negotiate ERTM. However you can not run SOCK_STREAM on a Basic
Mode connection.

But the real benefit for higher layer protocols is if you become a
SOCK_STREAM. Because you are MTU free now. Using SOCK_SEQPACKET with
ERTM or Basic Mode is not really much of a difference.

Especially with OBEX that has its own MTU anyway in the first place has
always been run on SOCK_STREAM so far, what is the different that you
expect by running it of SOCK_SEQPACKET with ERTM?

Regards

Marcel

Re: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[Piotr Zgórecki]

Marcel,

Allow me to quote GOEP this time :)
"
>From 7.1 L2CAP Interoperability Requirements
7.1.1 MTU option
According to [1], OBEX packets must fit completely within a single
L2CAP SDU, so an implementation shall either configure the L2CAP MTU
to be large enough to hold the largest OBEX packet or configure the
OBEX packet size to be small enough to fit within the L2CAP MTU. In
any case the OBEX packet size should be set as large as possible,
especially in the case that the Single Response Mode feature of IrOBEX
is not supported. By definition:
=95 The L2CAP MTU refers to the SDU size
=95 The SDU is the application packet (OBEX packet in GOEP)
"

So you can't hide the MTUs from OBEX. What is the point of using a
streaming socket then ?
I think it's a good illustration of the point I was trying to make in
my previous email. L2CAP uses SDUs, which unlike e.g. segments in TCP
_are_ exposed to the upper layers, and you'll find running away from
them rather difficult :)

Cheers,
Piotr

On 15 June 2011 15:21, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Tim,
>
>> > +enum obex_transport_format{
>> > + =A0 =A0 =A0OBEX_MT_STREAM ,
>> > + =A0 =A0 =A0OBEX_MT_SEQPACKET
>> > +};
>> > +
>> > And more important, I have no idea why are you doing this anyway. Even
>> > with L2CAP this should run over SOCK_STREAM.
>>
>> Is that really so? =A0I expect exposing L2CAP ERTM as a stream could bre=
ak protocols above that expect datagram-boundary preservation (eg RTP). =A0=
Or can break protocols that mandate that only one higher-layer packet exist=
s in each L2CAP SDU. =A0For these the socket needs to be packet based.
>>
>> So, my surprise is that ERTM is exposed as SOCK_STREAM. =A0So I do have =
an idea why the patch mentions sequenced packet...
>
> you can do both for ERTM actually. You can create SOCK_SEQPACKET and
> have it negotiate ERTM. However you can not run SOCK_STREAM on a Basic
> Mode connection.
>
> But the real benefit for higher layer protocols is if you become a
> SOCK_STREAM. Because you are MTU free now. Using SOCK_SEQPACKET with
> ERTM or Basic Mode is not really much of a difference.
>
> Especially with OBEX that has its own MTU anyway in the first place has
> always been run on SOCK_STREAM so far, what is the different that you
> expect by running it of SOCK_SEQPACKET with ERTM?
>
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>

RE: [PATCH 2/2] Bluetooth: FTP and OPP over L2CAP

[Li, Nami]

SGkgTWFyY2VsLCBQaW90ciwNCiAgSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggUGlvdHIgcG9pbnRz
LiANCiAgQnkgdGhlIHdheSwgaW4gbXkgb2JleGQgcGF0Y2hlcywgb25seSB3aGVuIEkgc3RhcnQg
TDJDQVAgY29ubmVjdGlvbiBvciBsaXN0ZW4gb24gTDJDQVAgc29jaywgSSBzZXQgdGhlIGlvIG1v
ZGUgdG8gTDJDQVBfTU9ERV9FUlRNIGFuZCB0aGUgdHJhbnNmZXIgbW9kZSB0byBTT0NLX1NFUVBB
Q0tFVC4gV2hlbiBzdGFydCBSRkNPTU0gY29ubmVjdGlvbiBvciBsaXN0ZW4gb24gUkZDT01NIHNv
Y2ssIHRoZSBpbyBtb2RlIGlzIHN0aWxsIEwyQ0FQX01PREVfQkFTSUMgYW5kIHRoZSB0cmFuc2Zl
ciBtb2RlIGlzIHN0aWxsIFNPQ0tfU0VRUEFDS0VULiBNeSBwYXRjaGVzIHN1cHBvcnQgYm90aCBP
QkVYIE9WRVIgTDJDQVAgYW5kIE9CRVggT1ZFUiBSRkNPTU0uDQoNCkJlc3Qgd2lzaGVzLg0KTmFt
aQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbGludXgtYmx1ZXRvb3RoLW93
bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWJsdWV0b290aC1vd25lckB2Z2VyLmtl
cm5lbC5vcmddIE9uIEJlaGFsZiBPZiBwaW90ci56Z29yZWNraUBhY2NlbnR1cmUuY29tDQpTZW50
OiAyMDEx5bm0NuaciDE15pelIDIwOjQ4DQpUbzogbGludXgtYmx1ZXRvb3RoQHZnZXIua2VybmVs
Lm9yZw0KQ2M6IHRpbS5ob3dlc0BhY2NlbnR1cmUuY29tDQpTdWJqZWN0OiBSRTogW1BBVENIIDIv
Ml0gQmx1ZXRvb3RoOiBGVFAgYW5kIE9QUCBvdmVyIEwyQ0FQDQoNCkhpIFRpbSwgTWFyY2VsLA0K
DQo+PiArZW51bSBvYmV4X3RyYW5zcG9ydF9mb3JtYXR7DQo+PiArICAgICBPQkVYX01UX1NUUkVB
TSAsDQo+PiArICAgICBPQkVYX01UX1NFUVBBQ0tFVA0KPj4gK307DQo+PiArDQo+PiBBbmQgbW9y
ZSBpbXBvcnRhbnQsIEkgaGF2ZSBubyBpZGVhIHdoeSBhcmUgeW91IGRvaW5nIHRoaXMgYW55d2F5
LiANCj4+IEV2ZW4gd2l0aCBMMkNBUCB0aGlzIHNob3VsZCBydW4gb3ZlciBTT0NLX1NUUkVBTS4N
Cj4NCj5JcyB0aGF0IHJlYWxseSBzbz8gIEkgZXhwZWN0IGV4cG9zaW5nIEwyQ0FQIEVSVE0gYXMg
YSBzdHJlYW0gY291bGQgYnJlYWsgcHJvdG9jb2xzIGFib3ZlIHRoYXQgPmV4cGVjdCBkYXRhZ3Jh
bS1ib3VuZGFyeSBwcmVzZXJ2YXRpb24gKGVnIFJUUCkuICBPciBjYW4gYnJlYWsgcHJvdG9jb2xz
IHRoYXQgbWFuZGF0ZSB0aGF0ID5vbmx5IG9uZSBoaWdoZXItbGF5ZXIgcGFja2V0IGV4aXN0cyBp
biBlYWNoIEwyQ0FQIFNEVS4gIEZvciB0aGVzZSB0aGUgc29ja2V0IG5lZWRzIHRvIGJlID5wYWNr
ZXQgYmFzZWQuDQo+DQo+U28sIG15IHN1cnByaXNlIGlzIHRoYXQgRVJUTSBpcyBleHBvc2VkIGFz
IFNPQ0tfU1RSRUFNLiAgU28gSSBkbyBoYXZlIGFuIGlkZWEgd2h5IHRoZSBwYXRjaCA+bWVudGlv
bnMgc2VxdWVuY2VkIHBhY2tldC4uLg0KPg0KPj4gSSBhc3N1bWVkIHRoYXQgT1BQIGFuZCBGVFAg
b3ZlciBMMkNBUCBhcmUgcmVxdWlyaW5nIGVMMkNBUCBhY3R1YWxseSANCj4+IHdoaWNoIGlzIHJl
LXByZXNlbnRlZCBhcyBhIHN0cmVhbS4NCj4NCj5ZZXMsIE9CRVggb3ZlciBMMkNBUCByZXF1aXJl
cyBlbmhhbmNlZCByZXRyYW5zbWlzc2lvbiBtb2RlLg0KDQpGcm9tIHRoZSBDb3JlIFNwZWNpZmlj
YXRpb24sIFZvbC4gMywgUGFydCBBLCBQdC4gNy4zIEVuY2Fwc3VsYXRpb24gb2YgU0RVczoNCiJJ
dCBpcyBhc3N1bWVkIHRoYXQgU0RVIGJvdW5kYXJpZXMgc2hhbGwgYmUgcHJlc2VydmVkIGJldHdl
ZW4gcGVlciB1cHBlciBsYXllciBlbnRpdGllcy4iDQoNClNEVSBpcyBieSBkZWZpbml0aW9uIGFu
IGFic3RyYWN0aW9uIGV4cG9zZWQgdG8gdGhlIHVwcGVyIGxheWVyLiBUaGlzIGFzc3VtcHRpb24g
cGVybWVhdGVzIGFsbCBvZiBCbHVldG9vdGggYW5kIGJyZWFraW5nIGl0IGNhbiBoYXZlIGRpcmUg
Y29uc2VxdWVuY2VzIGJvdGggZm9yIHByb2ZpbGVzIGFzc3VtaW5nIHRoZWlyIG1lc3NhZ2VzIG1h
cCAxOjEgdG8gU0RVcy4NCg0KQ2hlZXJzLA0KUGlvdHINCg0KVGhpcyBtZXNzYWdlIGlzIGZvciB0
aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCwg
cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgSWYgeW91IGhh
dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh
dGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSBvdGhlciB1c2Ugb2YgdGhlIGVtYWls
IGJ5IHlvdSBpcyBwcm9oaWJpdGVkLg0KTiAgICAgciAgeSAgIGIgWCAgx6d2IF4gKd66ey5uICsg
ICAgeyBuWyAgIC0gKSAgIHcqamcgICAeICAgICDdomovICAgeiDeliAgMiDemSAgICYgKd+hIGEg
IH8gIB4gRyAgIGggDyBqOit2ICAgdyDZpQ0K