On Wed, Dec 7, 2016 at 3:52 AM, Vincent Torri <[email protected]> wrote: > and fyi, ecore_con_local_win32 used to work before the migration to > eo. I tested it with a client/server, efreetd also was working
I guess one day it may have worked, but It's not now... I didn't investigate the whole set of changes to that file, it seems pretty isolated as it doesn't deal much with eo on its own. Then come to your other reply: > On Wed, Dec 7, 2016 at 6:50 AM, Vincent Torri <[email protected]> wrote: >> On Wed, Dec 7, 2016 at 12:50 AM, Gustavo Sverzut Barbieri >> <[email protected]> wrote: >>> Hi all, >>> >>> It seems ECORE_CON_LOCAL_* is broken on Windows given reports on >>> efreetd not working there, the code is very different from other >>> protocols, see ecore_con_local_win32.c >>> >>> Since I will replace Ecore_Con_Server with a wrapper on top of >>> Efl_Net, I'm wondering what to do... I don't have a windows machine or >>> windows development environment to write a new Efl_Net set of class >>> for it (if you do, please talk to me so I can get an SSH access). >>> >>> More than that, looking at local_win32.c I wonder how that would work, >>> since unlike UNIX path, it doesn't encode the service name/port in the >>> path, but the process id (I guess it's like the PID), thus one process >>> won't find the other... >>> >>> That's to say that legacy compatibility is not an issue in that case. >>> >>> Then what I propose to write an Efl_Net_Local_Fallback that uses a >>> local path to encode a localhost (127.0.0.1) TCP port. Then the logic >>> would be: >>> >>> - server: bind(127.0.0.1:0), getsockname() to check the port, >>> fprintf(fp, "%hu\n", ntohs(addr.sin_port))... \n is used to avoid >>> partial writes (unlikely) to file. >>> >>> - dialer (client): fopen() + fread() + verify trailing \n, then >>> connect to 127.0.0.1:$port >>> >>> - path is encoded like in UNIX, just "/" is replaced with "\" for >>> windows. "~" is also handled like in Windows, such as User\username... >>> >>> Then it would provide some usable solution where a native local >>> communication is not available... Of course this is fully testable on >>> UNIX as well, then we don't rely on Windows to test it. >>> >>> Agreed? >> >> no. >> >> named pipes are used. The name of a named pipe must have the following >> scheme : \\.\pipe\mypipename on local computer (or >> \\servername\pipe\mypipename on a remote computer) >> >> you keep thinking that unix and windows are the same... I don't think that, but I try to understand what code does, not solely hope it would work or complain without offering something insightful in exchange. Look at this code, which I isolated in its own function, now a new API to return the path (code itself is not modified): https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_con/ecore_con_local_win32.c#n390 if (!is_system) snprintf(buf, sizeof(buf), "\\\\.\\pipe\\%s%ld", name, GetProcessId(GetCurrentProcess())); else { const char *computername; computername = getenv("COMPUTERNAME"); snprintf(buf, sizeof(buf), "\\\\%s\\pipe\\%s%ld", computername, name, GetProcessId(GetCurrentProcess())); } I know nothing about Windows, but I know how to read code and read docs, then I search what is GetProcessId(): https://msdn.microsoft.com/en-us/library/windows/desktop/ms683215(v=vs.85).aspx Retrieves the process identifier of the specified process It should be using a delimiter and then "port", as other code does, since you use $PID, then how is one process going to find the other if it doesn't know the process id of the server? Since I'm proposing a FALLBACK system, I'd not use the same path as the actual implementation may use as it would clash. Instead I'd use another file, named closely to UNIX. Read my first email, this is a FALLBACK system that uses a FILE to indicate the TCP port on localhost, it's NOT using the CreateNamedPipe(). There are two purposes in this: - offer a fallback where a native local transport is not available (Windows, PlayStation, etc) - create a code that is testable and debugable on UNIX, where most developers work. ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
