Re: [E-devel] Work items towards 1.19

[Vincent T. <vin...@gm...>]

if i have read the code correctly, there are problems:

Efl_Net_Socket_Windows_Operation is an analogous of my IRP but you're
wrong in modifying it, this will not work

my error_check is not correctly ported

the _client|server_on_complete function MUST handle all the I/O
connections, that is, the connectiion of the client to the server, the
read I/O and the write I/O. It's not done

If you don't do exactly what I have done, and if you modify this code
based on 2 unrelated msdn doc, this will not work

Vincent



On Wed, Mar 22, 2017 at 10:53 PM, Gustavo Sverzut Barbieri
<bar...@gm...> wrote:
> On Wed, Mar 22, 2017 at 4:51 PM, Vincent Torri <vin...@gm...> wrote:
>> On Wed, Mar 22, 2017 at 1:04 PM, Gustavo Sverzut Barbieri
>> <bar...@gm...> wrote:
>>> Done, there is a branch that I could compile but not test (no Windows
>>> machine): devs/barbieri/efl_net_socket_windows
>>>
>>>
>>> https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/efl_net_socket_windows
>>>
>>> People that know windows API and could debug it please help. Look for the
>>> TODO. Vincent may be busy for some days.
>>
>> i fear you have changed a lot the code i have sent you. It is
>> obfuscated, I can't even know how I should read that code.
>
> Hi Vincent,
>
> It's not obfuscated, it's just integrated into the Eo and does all the
> Efl.Io/Efl.Net interfaces a dialer and server must respect to be used.
> Some properties are there to control the behavior as done by old
> ecore-con, such as controlling the maximum clients in a server and
> either queuing or rejecting the excess.
>
> I explained in the other email in private, but since the branch is
> public, it's better to explain it here:
>
>  - efl_net_socket_windows: represent the common part of a connection:
> how to read, write and close.
>
>     * It is not meant to be created directly by the end-user as it
> doesn't know how to create the HANDLE, it must be set from either a
> dialer or server which then call _efl_net_socket_windows_init()
>
>     * It does the ReadFile(), WriteFile() and CloseHandle().
>
>     * On _efl_net_socket_windows_io_start() it will create receive and
> send buffers of a fixed size. It will immediately start a ReadFile()
> to the read buffer, keeping efl_io_reader_can_read = false until read
> completes. It will mark efl_io_writer_can_write = true.
>
>     * When ReadFile() completes with success, it will mark
> "efl_io_reader_can_read = true". Doing so will notify users they can
> call efl_io_reader_read() without blocking. If the user reads
> everything, then "can_read = false". If there is available space to
> read more data, a new ReadFile() is called.
>
>     * while efl_io_writer_can_write == true, efl_io_writer_write()
> will append stuff to send buffer and call WriteFile(). If all space is
> consumed, then efl_io_writer_can_write = false. When WriteFile()
> completes, it will memmove() the remaining bits and allow more data to
> be written (efl_io_writer_can_write = true).
>
>     * Analogous to your IO_Request_Packet is
> Efl_Net_Socket_Windows_Operation. It allows you to create
> OVERLAPPED-based structure with 2 callbacks (success and failure, to
> mimic Efl_Promise/Efl_Future, which I may convert this code to that
> later). It will automatically call StartThreadpollIo(). When the I/O
> finishes it will call:
>         _efl_net_socket_windows_operation_succeeded(op, data)
>         _efl_net_socket_windows_operation_failed(op, error)
>
>
>  - efl_net_dialer_windows: the peer that connects (dials) to a server,
> it is a subclass of efl_net_socket_windows.
>     * Implements elf_net_dialer_dial(o, address) by calling CreateFile().
>
>     * Once created it's considered "resolved" and "connected", will
> set the remote/local socket address as requested by Efl_Net_Socket
> Interface (think of IP where you have getsockname() and
> getpeername()).
>
>
>  - efl_net_server_windows: the server side that accepts incoming connections.
>
>     * Efl_Net_Server is NOT a subclass of Efl_Net_Socket, it creates
> many Efl_Net_Socket, one for each incoming client and announces them
> with efl_net_server_client_announce(), that will emit "client,add"
> event.
>
>     * Implements efl_net_server_serve(o, address) by calling
> CreateNamedPipe() and then setting it to an internal Efl_Net_Socket
> (client) object stored in "pd->next_client". It will call
> ConnectNamedPipe() using OVERLAPPED, which in turn goes in the
> ThredpollIo using Efl_Net_Socket_Windows_Operation as explained above.
>
>     * When ConnectNamedPipe() finishes with success, it will check if
> the client limit is exceed, if:
>
>         1. limited and reject_excess: DisconnectNamedPipe() and reuse
> the socket with a new ConnectNamedPipe()
>
>         2. limited and NOT reject_excess: queue in
> pd->pending_clients, do not announce them to the application. Wait
> client count to be reduced to emit new client,add
>
>         3. not limited: emit client,add event with the socket. If it's
> used, then create a new Efl_Net_Socket_Window to wait for the next
> client, otherwise Disconnect and do a new connect to reuse socket.
>
>     * Each client that is announced is a HANDLE wrapped by
> Efl_Net_Socket_Windows, thus as explained above it can
> read/write/close (shared code).
>
>
>
>
>> Btw, you are mentionning 2 msdn pages which are completely unrelated
>> to the technic I have used
>
> I understand that, but I needed some reference to validate the calls
> and sequence.
>
> as I wrote in some "TODO vtorri", we need to confirm some stuff
> regarding StarThreapollIo(), such as if ReadFile() and WriteFile() can
> happen simultaneously, if we're called from a thread at
> _efl_net_socket_windows_io_completed()... If you can find examples
> more specifically about that, then add the link as well.
>
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890