It appears that a desire to support static binding did come up after all. When I wrote the email that John responded to I had been thinking this might be the case.So we now have Ashok and Markus promoting the idea of facilitating static binding.
There are many reasons both for and against this. One of the initial ones I am wary of is incompatibility if one stakeholder sets things to some fixed configuration and then other devices later get introduced to the same environment. If static binding *sometimes* works, then we can also have it *sometimes* not work. For example if we attempt to use the CoAP UDP portof 5683 and are successful most of the time clients might rely on that. Then when we don't get that port certain clients might fail. So I guess we're back to my original questions there to make sure we *should* try to facilitate explicit ports. (we already know that we could... so it's down to the matter of being the proper choice vs. being a viable choice). On 01/26/2016 09:36 PM, Markus Jung wrote: > Samsung Enterprise Portal mySingle > > Hello, > > if there is a change on the API for 1.1.0, please also put a Jira ticket. > > As far as I understood, there is an API to configure the port at > startup at the server and also at the client side. > > I also noticed that IoTivity by default uses a random port to bind the > server. That is a bit unpleasent if a generic client is used. > > Would be nice if the default CoAP UDP (5683) port is used as default > and only if it is not available or the API caller explicitely requests > another port a different port is used. > > But as it was said in the conversation already, a client can in > general not rely that a server is reachable with a certain port. > However, if the client and server is under of control of one > stakeholder the configuration could be known and a static port setting > used. Also in an environment that requires firewall settings it is > important to have static port numbers used. > > Best regards > > Markus > > ------- *Original Message* ------- > > *Sender* : Uze Choi<uzchoi at samsung.com> S6/Principal Engineer/IoT > Lab./Samsung Electronics > > *Date* : Jan 26, 2016 14:49 (GMT+09:00) > > *Title* : RE: [dev] Need API to set static "sid" and "port number". > > Hi Jon/John, > > I agree ?We know that the ?try? can be unsuccessful, so a discovery > fallback is inevitable.? So that we need implement rediscovery UI for > fallback case. > However, if try is successful, we can reduce the step to re-discover > which will bring the big benefit to user from UI perspective. > > How about including this issue into the Jira ticket for in this coming > 1.1.0 release? > Markus, could you help it? > > BR, Uze Choi > > *From:*iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *Light, > John J > *Sent:* Tuesday, January 26, 2016 6:38 AM > *To:* Jon A. Cruz; jjack.lee at samsung.com; Macieira, Thiago; > iotivity-dev at lists.iotivity.org > *Subject:* Re: [dev] Need API to set static "sid" and "port number". > > Jon, > > I don?t see any attempt to propose static port binding, so the request > doesn?t violate any OIC intent. In any case, since a node might > support multiple servers, static port binding wouldn?t work. > > I understand the request is to make a server ?try? to use a port that > it used in a previous run. We know that the ?try? can be > unsuccessful, so a discovery fallback is inevitable. > > John Light > > *From:*Jon A. Cruz [mailto:jonc at osg.samsung.com] > *Sent:* Monday, January 25, 2016 1:30 PM > *To:* Light, John J; jjack.lee at samsung.com; Macieira, Thiago; > iotivity-dev at lists.iotivity.org > *Subject:* Re: [dev] Need API to set static "sid" and "port number". > > One aspect here sounds like code is depending on IoTivity devices to > operate like some other common servers where HTTP is on port 80, > telnet is on port 23, ssh on port 22, SMTP is on port 25, etc. > Compliance with company IT policies, firewall requirements, vpn rules, > etc. might come into play there. > > If this is so, then a question would be to ask if such port-bound > services were counter to the OIC intent, within the OIC intent or > un-addressed by it. > > > On the other hand, if it is just code counting on finding a device by > using address+port as a key, then I would share concerns on such > software being fragile. > > On 01/22/2016 08:20 AM, Light, John J wrote: > > Jack Lee (?), > > In OCDoResource, you can supply a port number in the OCDevAddr > argument. Network layer will use it, just as in original > IoTivity. So the same functionality exists. > > I still have reservations about the design of counting on port > numbers persisting. > > John > > *From:*iotivity-dev-bounces at lists.iotivity.org > <mailto:iotivity-dev-bounces at lists.iotivity.org> > [mailto:iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *??? > *Sent:* Thursday, January 21, 2016 9:47 PM > *To:* Macieira, Thiago; iotivity-dev at lists.iotivity.org > <mailto:iotivity-dev at lists.iotivity.org> > *Subject:* Re: [dev] Need API to set static "sid" and "port number". > > - > > OCDoResource() must set port number. > > |How can forget it? If you right, then iotivity should be redesign. | > > |Because, OCDoResource() has port number dependency.| > > |If we support just one optional api, we can reduce > re-discovery problem.| > > |I don't understand why did yoy object to add "OPTIONAL" api > although it can provide very useful user exprience.| > > |And, old version iotivity could set port number... there is no > issue about development| > > ------- *Original Message* ------- > > *Sender*: Thiago Macieira<thiago.macieira at intel.com > <mailto:thiago.macieira at intel.com>> > > *Date*: 2016-01-22 14:19 (GMT+09:00) > > *Title*: Re: [dev] Need API to set static "sid" and "port number". > > On Friday 22 January 2016 02:25:47 jaekeun lee wrote: > > I didn't say that change the mechanism. > > I said, support the additional API for set to port number and sid or > > di(variable name is sid) is very useful and helpful. > > The experience depends on how the application is written > > How can fix this issue? > > - Presence Check -> Re-Discovery -> Check saved DI & discovered > DI -> change > > target's IP/PORT or > > - re configure every run > > These are very inconvenience . > > > > But, if server can set port, then re-configure only when server > not work(may > > be ip changed or port occupied). > > Just additional API. > > Forget the port number. If your other side is trying to depend on > the port > number, please redesign it. You cannot count on the port number > being free, so > your other side must be able to deal with the port number changing. > > For that matter, the IP might change after a reboot. Or even > without a reboot: > IPv6 temporary addresses change about once a day. Since you can't > count on the > IP being fixed, port numbers don't identify anything. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > *_Best Regards,_* > > ** > > ** > > *Dr.techn. Markus Jung * > > IoT, IoTivity, OIC | IoT Lab > > Software R&D Center | Samsung Electronics Co., Ltd > > Mobile+82 10 3304 8502 > > markus.jung at samsung.com > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160127/0f4eb8f5/attachment.html>
