That is an interesting question.
They are remnants of an implementation of slow response and block transfer. A
different approach to handling slow response was implemented and we must have
neglected to clean up completely. Recall that slow response is used for
servers that may not know their
Sup Fedora Buddy!
If you're on an older version of the code (not pulled in the last few
hours), the lookup for Wifi/Ethernet was done by the interface name.
We look up in
resource/csdk/connectivity/src/wifi_adapter/linux/cawifinwmonitor.c and
resource/csdk/connectivity/src/ethernet_adapter/linux
Hey!
That may be. I'm trying to run both the client and the server on a
laptop connected over WiFi. I'm deliberately trying to avoid
specifying anything about the underlying network, to let the stack
figure it out.
Cheers!
Gabriel
That's the ocserver, not my server.
Hey!
... and just to add a bit of info, when I'm running the server, I'm
not seeing any new sockets with netstat.
Like, I did netstat -apn > netstat.before, then I ran the server, then
netstat -apn > netstat.after, and no diff.
HTH,
Gabriel
In the OCEntityHandlerResponse struct there is a
OCResponseHandle *responseHandle;
That isn?t used anywhere. Also there is a
OCCanceResponse(OCResponseHandle) that doesn?t do anything.
Can these be culled?
On Tuesday 05 May 2015 22:44:22 Keane, Erich wrote:
> In order to get this to work, I'd suggest altering the "matchName" in
> the first one above (wifi_adapter) to "wlp".
Make that "wl" for WLAN, "ww" for WWAN (including 3G/4G modems), "sl" for
SLIP, and "en" for Ethernet.
http://www.freedesktop
Hey!
I'll definitely do that, but I also have the problem that the samples
don't work for me either. In the meantime, can you please give me two
command lines for occlient and ocserver that are supposed to cause
occlient and occserver to see each other?
For example, I've tried
out/linux/x86_64/re
Hey!
On Tue, May 5, 2015 at 6:25 PM, Lenahan, Charlie
wrote:
> I would use something instead of OC_NA_QOS, cause I don?t think that?s
> valid.
> Also if you run loop only calls OCProcess every 2 seconds , then things
> will be very slow.
OK. I've since reduced the timeout to 100ms in both the cl
Which OS are you running? Can you run an IFConfig for me, and c&p the
results?
On Tue, 2015-05-05 at 21:47 +0300, Schulhof, Gabriel wrote:
> That's the ocserver, not my server.
I haven't been able to look super closely, but I think this is the issue.
Your call to the OCDoResource on the client does a GET (or discovery?), however
it doesn't specify which device to do a GET on! The "light" needs to specify
the IP address of the request.
Check out resource/csdk/stack/sa
Hi Gabriel,
Can you include a log?
What I'm looking for is to determined that OCProcess() is actually being called
in a loop.
Thanks,
Joseph Morrow
-Original Message-
From: iotivity-dev-bounces at lists.iotivity.org
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Schulh
>___
>iotivity-dev mailing list
>iotivity-dev at lists.iotivity.org
>https://lists.iotivity.org/mailman/listinfo/iotivity-dev
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5859 bytes
Desc: not available
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150505/bedf51aa/attachment.p7s>
Hi!
I'm trying to write a simple client/server pair in C using
OCCreateResouce on the server side and OCDoResource on the client side
to find the server. I'm not getting any communication between the two.
That is, neither the OCEntityHandler of the server is ever getting
called, nor is the OCClien
On 05/05/2015 11:47 AM, Schulhof, Gabriel wrote:
> Hey!
>
> ... and just to add a bit of info, when I'm running the server, I'm
> not seeing any new sockets with netstat.
>
> Like, I did netstat -apn > netstat.before, then I ran the server, then
> netstat -apn > netstat.after, and no diff.
>
Wh
15 matches
Mail list logo
