On Mon, 1 Aug 2016 15:11:18 +0200 Chidambar Zinnoury <chidam...@illogict.fr> said:
> Hi. > > On Mon, 1 Aug 2016 22:10:44 +1000 David Seikel <onef...@gmail.com> > wrote: > > > On Mon, 1 Aug 2016 09:01:13 -0300 Gustavo Sverzut Barbieri > > <barbi...@gmail.com> wrote: > > > > > On Mon, Aug 1, 2016 at 1:26 AM, David Seikel <onef...@gmail.com> > > > wrote: > > > > On Mon, 1 Aug 2016 00:50:31 -0300 Gustavo Sverzut Barbieri > > > > <barbi...@gmail.com> wrote: > > > > > > > >> Hi all, > > > >> > > > >> I'm entitled to review the new Eo API for Ecore_Con.h. Find below > > > >> my first draft proposal and after the "code" you can see my > > > >> detailed review of current code and competitors. > > > >> > > > >> Please reply in line with your points. As the email is > > > >> super-long, PLEASE cut non-relevant points and text so we can > > > >> easily see what you want to mean. > > > > > > > > <big snip per request> > > > > > > > > Two things. > > > > > > > > Some of those other APIs include a "family", IPv4 or IPv6. We > > > > could probably figure that out based on the structure of the IP > > > > address passed in, so no need to actually pass the family to > > > > API. Do we already do that? (I have public IPv6 addresses at > > > > home.) > > > > > > > > I want to experiment with other protocols, mostly SCTP, which is > > > > basically a cross between TCP and UDP. I wonder if we can support > > > > that? > > > > > > the current API takes a string, thus will either resolve/parse the > > > address to IPv4 or IPv6 then use that. > > > > > > in my proposal I'm using a resolved address. We'd need to introduce > > > a resolver (also async) and with that you chain. Ideally this will > > > force people to cache the name resolution since they must use that > > > anyway. > > > > > > Other folks such as Qt offer a "hostFound" to notify name > > > resolution, but then you're not able to easily cache. AFAIR you can > > > keep the address and on a second call use that address to connect > > > (different method). > > > > > > As for SCTP, likely we can support, but I never did anything with > > > it. > > > > Neither have I, but a friend thinks it might be useful for virtual > > world work, and he could be correct. Hence my desire to experiment > > with it. Currently Second Life and OpenSim use a combination of TCP > > and UDP, so a protocol that's basically a cross between them might > > work wonders. > > I did play (and did some interesting stuff) with SCTP while I was at > Motorola Research Lab: I worked on multihoming, multipath and stuff for > seamless roaming. > > Having basic SCTP support is *really* simple to implement for the > end-application (basically change the protocol on socket creation, and > you’re good to go), however, we may want to have ways to get several > addresses (on both local and distant sides) for multihoming/multipath. > This would also be useful for multipath TCP. hmm - would this then not be doable later by adding api's to get an iterator ot list of strings of addresses? 99% of people will not need this complexity but i'd be easy to add later for those that want/need multi homing? > The biggest problem would be NAT traversal as it is still not > standardized: see latest draft > https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-09 > > Cheers. > > Chidambar > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
