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. 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
