Jay,

Thank you for the additional information.  I see now why you had this problem.  
It does seem to be fixed in the current master.  You may be able to work around 
the issue for 1.0  by omitting  the "coap://" prefix, which is not really 
needed since the stack discards it and adds it later.

I sympathize with your suggestion that we update 1.0.  This is the least of the 
reasons we should update 1.0.

John



-----Original Message-----
From: ??? [mailto:[email protected]] 
Sent: Thursday, November 05, 2015 5:54 PM
To: Light, John J; Macieira, Thiago; iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Pre-defined length for the Host Info. is not long enough

Hi, John,

Let me share more information about the IoTivity stack & the logic that I'm 
using now.

The version of the IoTivity Stack is 1.0 (commit id:
e12c8a3bbdbe28820947d5994f9cf0b76d1f2fe5)

And as I mentioned before, I was using "constructResourceObject" API in order 
to communicate with an resource which is not discoverable. (Registered only 
with "OC_ACTIVE flag).

When I insert the host information with "scheme://[address(ipv6)]:port"
format through that API,
I get this error message from the OCResource.cpp (at the end of OCResource 
class constructor) (I've also added "printf" inside the stack so that I could 
see the actual string that the stack uses when checking its length)

=> Error :
        terminate called after throwing an instance of 'std::length_error'
          what():  host address is too long.
        @@@@@@@@@@@@ HOST : coaps://[fe80::a00:27ff:feaf:f911]:50272Aborted
(core dumped)    <=== log which "printf" prints..

When I tweaked my pc to use only IPv4 & insert host info. with format like 
"coaps://192.168.0.x:xxxx" 
into the API "constructResourceObject", it worked fine(meaning, I was able to 
communicate with the resource in remote without resource discovery step).

Again, the stack version is 1.0, not the latest code in the stack. 

Would this information helpful enough for you to find the one that you're 
looking for?
Please let me know if you need more testing infor. on this issue. :)

One question though, who could provide a patch for this issue(if it's necessary 
one.)on IoTivity ver. 1.0 ??


Thank you.
Jay.


-----Original Message-----
From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- 
[email protected]] On Behalf Of Light, John J
Sent: Friday, November 06, 2015 6:59 AM
To: Macieira, Thiago; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Pre-defined length for the Host Info. is not long enough

Thiago,

The code does indeed pull out the zone ID and zero it before converting so the 
length is predictable.

Of course, the zone ID is restored after converting back to binary.

John

-----Original Message-----
From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- 
[email protected]] On Behalf Of Thiago Macieira
Sent: Thursday, November 05, 2015 1:32 PM
To: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Pre-defined length for the Host Info. is not long enough

On Thursday 05 November 2015 16:00:46 Light, John J wrote:
> Jay,
> 
> Please provide more information about your issue.  I originally wrote 
> the data structures you are talking about, and I am concerned there 
> might be a larger problem now.

> The host address field should only contain the address string itself.  
> The longest of these is a full IPv6 address:
> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, which is 39 bytes long, plus one
> for a terminating null.   What other information are you seeing in the
> string?

The ZoneID might be added to that, which is one percent sign followed by a zone 
ID of platform-specific length limit. On Linux, that's IFNAMESIZ (16 bytes), 
but on Windows I've seen a full UUID, including the curly braces, added there.

Unless the ZoneID is removed from the address and placed in a separate scope ID 
/ interface index variable in the structure. There is such a field in 
CAEndpoint_t, so the only question is whether the called properly split the 
address+zoneid and filled in the fields correctly.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Reply via email to