kimcinoo
/
efl
forked from enlightenment/efl
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
efl/src/Makefile_Ecore_Con.am

279 lines
9.1 KiB
Plaintext
Raw Permalink Normal View History

merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
### Library
dist rule: add files to EXTRA_DIST2 inconditionally Summary: ecore_con and ethumb were adding files to EXTRE_DIST confitionally Reviewers: cedric, zmike, raster Reviewed By: zmike Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8558
2019-04-04 07:39:05 -07:00
ecore_con_eolian_files_common = \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_socket.eo \
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets. The low level I/O primitives are powerful but adds some complexity to use, for bi-directional streaming communication one ends creating two Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can operate. Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this will allow the socket, be a dialer or a server client, to be operated as a single handle that internally carries about the buffering for you. As one can see in the examples, compared to their "manual" alternatives they are very easy to use, ressembling Ecore_Con_Server/Ecore_Con_Client, but also offers line-based delimiters and the possibility to let the socket to handle queueing for you in case you received partial messages (just do not read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
lib/ecore_con/efl_net_socket_simple.eo \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_socket_fd.eo \
lib/ecore_con/efl_net_socket_tcp.eo \
efl_net_dialer_udp: "connect" to an UDP server to send and receive data. Like existing ecore_con code, this does not use SOCKSv5 UDP proxy. It's kinda cumbersome to add since requires a keep alive TCP connection to the server, a second UDP channel and framing around the original UDP frame. Added UDP_CORK (if present) to match TCP_UDP present in TCP sockets, this allows one to execute multiple write() calls that will result in a single datagram, generated when CORK becomes FALSE again. The efl_io_copier_example.c now accepts this as output. There is no input UDP as there is no way to notify the server of a connection (since such thing doesn't exit), usually servers react after a datagram is received, replying to the source.
2016-10-18 13:51:59 -07:00
lib/ecore_con/efl_net_socket_udp.eo \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_dialer.eo \
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets. The low level I/O primitives are powerful but adds some complexity to use, for bi-directional streaming communication one ends creating two Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can operate. Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this will allow the socket, be a dialer or a server client, to be operated as a single handle that internally carries about the buffering for you. As one can see in the examples, compared to their "manual" alternatives they are very easy to use, ressembling Ecore_Con_Server/Ecore_Con_Client, but also offers line-based delimiters and the possibility to let the socket to handle queueing for you in case you received partial messages (just do not read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
lib/ecore_con/efl_net_dialer_simple.eo \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_dialer_tcp.eo \
efl_net_dialer_udp: "connect" to an UDP server to send and receive data. Like existing ecore_con code, this does not use SOCKSv5 UDP proxy. It's kinda cumbersome to add since requires a keep alive TCP connection to the server, a second UDP channel and framing around the original UDP frame. Added UDP_CORK (if present) to match TCP_UDP present in TCP sockets, this allows one to execute multiple write() calls that will result in a single datagram, generated when CORK becomes FALSE again. The efl_io_copier_example.c now accepts this as output. There is no input UDP as there is no way to notify the server of a connection (since such thing doesn't exit), usually servers react after a datagram is received, replying to the source.
2016-10-18 13:51:59 -07:00
lib/ecore_con/efl_net_dialer_udp.eo \
WIP: efl.net: Introduce Efl.Net.Dialer.Http This class implements the Efl.Net.Dialer interface using libcurl to perform HTTP requests. That means it's an Efl.Net.Dialer, Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with Efl.Io.Copier as demonstrated in the efl_io_copier_example.c
2016-08-19 20:55:26 -07:00
lib/ecore_con/efl_net_dialer_http.eo \
efl_net_dialer_websocket: EFL now does WebSocket! The Efl.Net.Dialer.Websocket is just like other Efl.Net.Dialers: you can dial, you can close, monitor connected/address resolved and so on. And you can use WebSocket primitives and events such as text_send(), binary_send(), ping() and close_request() (since WebSockets use a close process where you should state a close reason). See efl_net_dialer_websocket_example.c Even if WebSocket is a message-based protocol (like "packets" from UDP), you can use efl_net_dialer_websocket_streaming_mode_set() to tell it to handle text or binary messages as a stream. Then all the Efl.Io.Reader and Efl.Io.Writer APIs work as expected, see efl_io_copier_example.c updates.
2016-08-29 20:28:00 -07:00
lib/ecore_con/efl_net_dialer_websocket.eo \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_server.eo \
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets. The low level I/O primitives are powerful but adds some complexity to use, for bi-directional streaming communication one ends creating two Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can operate. Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this will allow the socket, be a dialer or a server client, to be operated as a single handle that internally carries about the buffering for you. As one can see in the examples, compared to their "manual" alternatives they are very easy to use, ressembling Ecore_Con_Server/Ecore_Con_Client, but also offers line-based delimiters and the possibility to let the socket to handle queueing for you in case you received partial messages (just do not read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
lib/ecore_con/efl_net_server_simple.eo \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_server_fd.eo \
ecore_con: add an intermediate Efl.Net.Server.Ip
2017-09-29 14:12:03 -07:00
lib/ecore_con/efl_net_server_ip.eo \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_server_tcp.eo \
efl_net_server_udp: initial UDP server. This is the initial UDP server that works similarly to the TCP one, however under the hood it's widely different since the socket is reused for all "clients", thus needs a new Efl.Net.Server.Udp.Client (Efl.Net.Socket) as Efl.Net.Socket.Udp exposes the fd and options such as 'cork', which would interfere in other clients. The main socket will read the packets and find an existing client to feed it. If no client exists, then it will create one if not overr limit. Since there is no kernel-queuing as done by listen()/accept(), the 'no reject' case will just accept the client anyway. Next commits will improve UDP server handling with some advanced features: - join multicast groups - bind to a specific interface (SO_BINDTODEVICE) - block packets going out of local network (SO_DONTROUTE) - specify priorities (SO_PRIORITY)
2016-10-21 08:24:02 -07:00
lib/ecore_con/efl_net_server_udp.eo \
lib/ecore_con/efl_net_server_udp_client.eo \
efl_net_socket_ssl: initial SSL wrapper. This is the first step towards SSL connections on top of sockets, with an example on how to upgrade a dialer and a server client using TCP.
2016-10-28 17:48:19 -07:00
lib/ecore_con/efl_net_socket_ssl.eo \
lib/ecore_con/efl_net_ssl_context.eo \
efl_net_{server,dialer}_ssl: TCP + SSL easy to use. in the previous commit we're manually upgrading an existing TCP socket to SSL. It is desired since some protocols need to negotiate, like STARTTLS and the likes Now we offer 2 classes that does autostart SSL once the socket is ready.
2016-10-31 20:31:56 -07:00
lib/ecore_con/efl_net_dialer_ssl.eo \
lib/ecore_con/efl_net_server_ssl.eo \
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
lib/ecore_con/efl_net_control_access_point.eo \
lib/ecore_con/efl_net_control_technology.eo \
Efl.Net.Control.Manager (from Efl.Net.Control) Ref https://phab.enlightenment.org/T6847 Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
2018-04-06 02:06:56 -07:00
lib/ecore_con/efl_net_control_manager.eo \
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
lib/ecore_con/efl_net_session.eo \
ecore-con: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in evas and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de> Differential Revision: https://phab.enlightenment.org/D8108
2019-03-05 14:00:37 -08:00
lib/ecore_con/efl_net_ip_address.eo
Build system: Clean up the generation of sources from eolian. This cleans up a lot of the build system. This makes everything consistent, clean, less redundant and also fixes the issue of make clean not cleaning up generated files.
2014-10-02 08:52:45 -07:00
dist rule: add files to EXTRA_DIST2 inconditionally Summary: ecore_con and ethumb were adding files to EXTRE_DIST confitionally Reviewers: cedric, zmike, raster Reviewed By: zmike Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8558
2019-04-04 07:39:05 -07:00
ecore_con_eolian_files_windows = \
implement efl_net_{socket,dialer,server}_windows This is the local socket for windows, analogous to AF_UNIX. `Efl_Net_Socket_Windows` is the base class doing `ReadFile()` and `WriteFile()` using overlapped I/O, as well as the close procedure (`FlushFileBuffers()`, `DisconnectNamedPipe()` and `CloseHandle()`). These are done on top of an existing HANDLE that is set by `Efl_Net_Dialer_Windows` (from `CreateFile()`) or `Efl_Net_Server_Windows` (from `CreateNamedPipe()`). The overlapped I/O will return immediately, either with operation completed or `ERROR_IO_PENDING`, which means the kernel will execute that asynchronously and will later `SetEvent(overlapped.hEvent)` which is an event we wait on our main loop. That `overlapped` handle must exist during the call lifetime, thus cannot be bound to `pd`, as we may call `CancelIo()` but there is no guarantee the memory won't be touched, in that case we keep the overlapped around, but without an associated object. Windows provides no notification "can read without blocking" or non-blocking calls that returns partial data. The way to go is to use these overlapped I/O, with an initial `ReadFile()` to an internal buffer, once that operation finishes, we callback the user to says there is something to read (`efl_io_reader_can_read_set()`) and wait until `efl_io_reader_read()` is called to consume the available data, then `ReadFile()` is called again to read more data to the same internal buffer. Likewise, there is no "can write without blocking" or non-blocking calls that sends only partial data. The way to go is to get user bytes in `efl_io_writer_write()` and copy them in an internal buffer, then call `WriteFile()` on that and inform the user nothing else can be written until that operation completes (`efl_io_writer_can_write_set()`). This is cumbersome since we say we "sent" stuff when we actually didn't, it's still in our internal buffer (`pd->send.bytes`), but nonetheless the kernel and the other peer may be adding even more buffers, in this case we need to do a best effort to get it delivery. A particular case is troublesome: `write() -> close()`, this may result in `WriteFile()` pending, in this case we wait using `GetOverlappedResult()`, *this is nasty and may block*, but it's the only way I see to cope with such common use case. Other operations, like ongoing `ReadFile()` or `ConnectNamedPipe()` will be canceled using `CancelIo()`. Q: Why no I/O Completion Port (IOCP) was used? Why no CreateThreadpoolIo()? These perform much better! A: These will call back from secondary threads, but in EFL we must report back to the user in order to process incoming data or get more data to send. That is, we serialize everything to the main thread, making it impossible to use the benefits of IOCP and similar such as CreateThreadpoolIo(). Since we'd need to wakeup the main thread anyways, using `OVERLAPPED.hEvent` with `ecore_main_win32_handler_add()` does the job as we expect. Thanks to Vincent Torri (vtorri) for his help getting this code done with an example on how to do the NamedPipe handling on Windows.
2017-03-22 00:29:16 -07:00
lib/ecore_con/efl_net_socket_windows.eo \
lib/ecore_con/efl_net_dialer_windows.eo \
lib/ecore_con/efl_net_server_windows.eo
dist rule: add files to EXTRA_DIST2 inconditionally Summary: ecore_con and ethumb were adding files to EXTRE_DIST confitionally Reviewers: cedric, zmike, raster Reviewed By: zmike Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8558
2019-04-04 07:39:05 -07:00
ecore_con_eolian_files_unix = \
addded efl_net_{socket,dialer,server}_unix This introduces AF_UNIX server and dialer, these are not available on Windows as in that platform we'll create a custom class for native 'local' communication. In the future we can add a wrapper class Efl.Net.Local that will use the class for each platform, but won't expose its details. For instance, if we ever expose 'credentials' (which I didn't because they are not portable), then it doesn't make sense to try to match that on Windows. The 'Efl.Net.Local' would just stick to the basics: Reader, Writer and Closer APIs.
2016-10-26 13:57:37 -07:00
lib/ecore_con/efl_net_socket_unix.eo \
lib/ecore_con/efl_net_dialer_unix.eo \
lib/ecore_con/efl_net_server_unix.eo
dist rule: add files to EXTRA_DIST2 inconditionally Summary: ecore_con and ethumb were adding files to EXTRE_DIST confitionally Reviewers: cedric, zmike, raster Reviewed By: zmike Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8558
2019-04-04 07:39:05 -07:00
ecore_con_eolian_files = $(ecore_con_eolian_files_common)
if HAVE_WINDOWS
ecore_con_eolian_files += $(ecore_con_eolian_files_windows)
else
ecore_con_eolian_files += $(ecore_con_eolian_files_unix)
addded efl_net_{socket,dialer,server}_unix This introduces AF_UNIX server and dialer, these are not available on Windows as in that platform we'll create a custom class for native 'local' communication. In the future we can add a wrapper class Efl.Net.Local that will use the class for each platform, but won't expose its details. For instance, if we ever expose 'credentials' (which I didn't because they are not portable), then it doesn't make sense to try to match that on Windows. The 'Efl.Net.Local' would just stick to the basics: Reader, Writer and Closer APIs.
2016-10-26 13:57:37 -07:00
endif
WIP: efl.net: Introduce Efl.Net.Dialer.Http This class implements the Efl.Net.Dialer interface using libcurl to perform HTTP requests. That means it's an Efl.Net.Dialer, Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with Efl.Io.Copier as demonstrated in the efl_io_copier_example.c
2016-08-19 20:55:26 -07:00
ecore_con_eolian_type_files = \
efl_net: move error COULDNT_RESOLVE_HOST to broader scope. This error is shared by Dialer and Server, will also be used by IP resolution.
2016-12-11 16:17:15 -08:00
lib/ecore_con/efl_net_types.eot \
efl_net_socket_ssl: initial SSL wrapper. This is the first step towards SSL connections on top of sockets, with an example on how to upgrade a dialer and a server client using TCP.
2016-10-28 17:48:19 -07:00
lib/ecore_con/efl_net_http_types.eot \
lib/ecore_con/efl_net_ssl_types.eot
WIP: efl.net: Introduce Efl.Net.Dialer.Http This class implements the Efl.Net.Dialer interface using libcurl to perform HTTP requests. That means it's an Efl.Net.Dialer, Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with Efl.Io.Copier as demonstrated in the efl_io_copier_example.c
2016-08-19 20:55:26 -07:00
Build system: Clean up the generation of sources from eolian. This cleans up a lot of the build system. This makes everything consistent, clean, less redundant and also fixes the issue of make clean not cleaning up generated files.
2014-10-02 08:52:45 -07:00
ecore_con_eolian_c = $(ecore_con_eolian_files:%.eo=%.eo.c)
ecore_con_eolian_h = $(ecore_con_eolian_files:%.eo=%.eo.h) \
ecore-con: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in evas and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de> Differential Revision: https://phab.enlightenment.org/D8108
2019-03-05 14:00:37 -08:00
$(ecore_con_eolian_type_files:%.eot=%.eot.h)
Ecore con client: Migrate to eo.
2014-08-22 05:14:59 -07:00
Ecore con: Start migration to eo.
2014-08-22 03:11:41 -07:00
BUILT_SOURCES += \
Build system: Clean up the generation of sources from eolian. This cleans up a lot of the build system. This makes everything consistent, clean, less redundant and also fixes the issue of make clean not cleaning up generated files.
2014-10-02 08:52:45 -07:00
$(ecore_con_eolian_c) \
$(ecore_con_eolian_h)
autotools: add option to enable eo file install Summary: eolian is not stable so these files should not be distributed by default in order to discourage relying on something which may break later fix T7676 Reviewers: bu5hm4n Reviewed By: bu5hm4n Subscribers: cedric, #reviewers, #committers Tags: #efl Maniphest Tasks: T7676 Differential Revision: https://phab.enlightenment.org/D8339
2019-03-14 09:43:33 -07:00
if INSTALL_EO_FILES
Ecore con: Start migration to eo.
2014-08-22 03:11:41 -07:00
ecoreconeolianfilesdir = $(datadir)/eolian/include/ecore-@VMAJ@
ecoreconeolianfiles_DATA = \
WIP: efl.net: Introduce Efl.Net.Dialer.Http This class implements the Efl.Net.Dialer interface using libcurl to perform HTTP requests. That means it's an Efl.Net.Dialer, Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with Efl.Io.Copier as demonstrated in the efl_io_copier_example.c
2016-08-19 20:55:26 -07:00
$(ecore_con_eolian_files) \
$(ecore_con_eolian_type_files)
autotools: add option to enable eo file install Summary: eolian is not stable so these files should not be distributed by default in order to discourage relying on something which may break later fix T7676 Reviewers: bu5hm4n Reviewed By: bu5hm4n Subscribers: cedric, #reviewers, #committers Tags: #efl Maniphest Tasks: T7676 Differential Revision: https://phab.enlightenment.org/D8339
2019-03-14 09:43:33 -07:00
endif
Ecore con: Start migration to eo.
2014-08-22 03:11:41 -07:00
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
dist rule: add files to EXTRA_DIST2 inconditionally Summary: ecore_con and ethumb were adding files to EXTRE_DIST confitionally Reviewers: cedric, zmike, raster Reviewed By: zmike Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8558
2019-04-04 07:39:05 -07:00
$(ecore_con_eolian_files_common) \
$(ecore_con_eolian_files_unix) \
$(ecore_con_eolian_files_windows) \
$(ecore_con_eolian_type_files)
Ecore con: Start migration to eo.
2014-08-22 03:11:41 -07:00
WIP: efl.net: Introduce Efl.Net.Dialer.Http This class implements the Efl.Net.Dialer interface using libcurl to perform HTTP requests. That means it's an Efl.Net.Dialer, Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with Efl.Io.Copier as demonstrated in the efl_io_copier_example.c
2016-08-19 20:55:26 -07:00
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
lib_LTLIBRARIES += lib/ecore_con/libecore_con.la
each module install headers in their own directory. SVN revision: 82895
2013-01-16 11:28:30 -08:00
installed_ecoreconmainheadersdir = $(includedir)/ecore-con-@VMAJ@
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
dist_installed_ecoreconmainheaders_DATA = \
lib/ecore_con/Ecore_Con.h \
ecore_con: add an Efl_Net.h
2017-10-27 18:48:16 -07:00
lib/ecore_con/Efl_Net.h \
Ecore_Con: Fix make distcheck
2015-06-22 23:17:45 -07:00
lib/ecore_con/Ecore_Con_Eet.h \
lib/ecore_con/Ecore_Con_Eet_Legacy.h \
ecore-con: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in evas and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de> Differential Revision: https://phab.enlightenment.org/D8108
2019-03-05 14:00:37 -08:00
lib/ecore_con/Ecore_Con_Eet_Eo.h \
lib/ecore_con/ecore_con_eet_base_eo.h \
lib/ecore_con/ecore_con_eet_base_eo.legacy.h \
lib/ecore_con/ecore_con_eet_client_obj_eo.h \
lib/ecore_con/ecore_con_eet_client_obj_eo.legacy.h \
lib/ecore_con/ecore_con_eet_server_obj_eo.h \
lib/ecore_con/ecore_con_eet_server_obj_eo.legacy.h
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
Ecore con: Start migration to eo.
2014-08-22 03:11:41 -07:00
nodist_installed_ecoreconmainheaders_DATA = \
Build system: Clean up the generation of sources from eolian. This cleans up a lot of the build system. This makes everything consistent, clean, less redundant and also fixes the issue of make clean not cleaning up generated files.
2014-10-02 08:52:45 -07:00
$(ecore_con_eolian_h)
Ecore con: Start migration to eo.
2014-08-22 03:11:41 -07:00
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
lib_ecore_con_libecore_con_la_SOURCES = \
lib/ecore_con/ecore_con_alloc.c \
lib/ecore_con/ecore_con.c \
ecore_con - move libproxy to a slave binary with stdin/out msging so here's the ugly problem. libproxy. yes. we've discussed memory usage (e.g. it may have to execute javascript and pull in lots of deps etc.) but we dlopene'd on the fly. ok... but this didn't solve another issue i hit: libproxy was causing enlightenment to abort(). some internal bit of libproxy was raising a c++ exception. this wasn't caught. this causes an abort(). takes down your entire desktop. FANTASTIC. this is bad. i wouldnt' expect a library we depend on to be THIS anti-social but libproxy seemingly is. it SHOULd catch its error sand just propagate back to us so we can handle gracefully. there reall is no way around this - isolate libproxy. it's even worse that libproxy can load arbitrary modules that come from anywhere sho who knows what issues this can cause. isolation is the best solution i can think of. so this makes an elf+net_proxy_helper we spawn the first time we need a proxy lookup. we re-use that binary again and again until it exits (it should exit after 10 seconds of being idle with no requests coming in/pending). it'll respawn again later if needed. this involves now the efl net threads having to marshall back to mainloop to do the spawn and to write to the proxy process (reading is done by async exe data events and the data is passed down a thread queue to the waitng efl net thread). if the exe dies with pending requests unanswered then it's respawned again and the req's are re-sent to it... just in case. it has a limit on how often it'll respawn quickly. this seems to work in my limited testing. this ALSO now isolates memory usage of libproxy to another slave process AND this process will die taking its memory with it once it's been idle for long enough. that;s also another good solution to keeping libproxy impact at bay.
2017-01-08 05:57:54 -08:00
lib/ecore_con/ecore_con_proxy_helper.c \
ecore_con: Ecore_Con_Server now on top of Efl_Net! This is a major work and unfortunately couldn't be split into smaller pieces as old code was highly coupled. Ecore_Con_Server is now a wrapper around Efl_Net_Dialer_Simple (ecore_con_server_connect()) and Efl_Net_Server_Simple (ecore_con_server_add()), doing all that the original version did with some fixes so ecore_con_ssl_server_upgrade() and ecore_con_ssl_client_upgrade() are more usable -- see the examples and -t/--type=tcp+ssl. I tried to be bug-compatible, with code annotations where things doesn't make sense. This was based on ecore_con_suite tests and some manual experimenting with the examples, these can be helpful if you find regressions (report/assign to me).
2016-12-07 07:34:28 -08:00
lib/ecore_con/ecore_con_legacy.c \
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
lib/ecore_con/ecore_con_eet.c \
lib/ecore_con/ecore_con_socks.c \
lib/ecore_con/ecore_con_url.c \
ecore-con-url- split out the curl dleopener and resolver and headers this splits out out "manual" dlopen (eina_module_load) of curl into its own .c file and special header out of ecore_con_url.c to tidy up that code a bit and isolate our curl magic loading/handling
2015-09-02 20:22:01 -07:00
lib/ecore_con/ecore_con_url_curl.c \
lib/ecore_con/ecore_con_url_curl.h \
ecore_con: add http_parser static lib. Summary: This lib would be used in efl_network_websocket. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric Reviewed By: cedric Differential Revision: https://phab.enlightenment.org/D3244 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-11-09 15:52:11 -08:00
static_libs/http-parser/http_parser.c \
static_libs/http-parser/http_parser.h \
ecore-con - simplify down to a single libc resolver Summary: this removes the cares/ares based resolver and the compiled-in dns.c resolver, modified the getaddrinfo based resolver to use threads not forking (almost halving its size) and now makes that the only resolver we have. getaddrinfo handles ipv6 and ipv4 (according to docs). this simplifies code paths, drops code size of the efl tree by about 11k lines of code, makes it easier to test and more robust to future changes with ip resolving as it now just relies on libc. we won't have coverity complaints on dns.c imported code anymore to fix and don't have tokeep up with bugfixes/security from the upstream imported code. this means we use a single resolver on all platforms (windows, mac, linux) as opposed to before where cares was used for windows, and dns.c on linux/mac. oh and the forking original was broken since our move to eo too. so it couldnt even compile if enabled, letalone work. so fix bug with missing /etc/resolv.conf that dns.c couldn't cope with, fix testability, fix maintainability and reduce efl codebase size. this fixes T3668 @fix @improve Subscribers: cedric, seoz, jpeg Maniphest Tasks: T3668 Differential Revision: https://phab.enlightenment.org/D3971
2016-05-22 01:03:26 -07:00
lib/ecore_con/ecore_con_private.h \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_socket.c \
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets. The low level I/O primitives are powerful but adds some complexity to use, for bi-directional streaming communication one ends creating two Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can operate. Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this will allow the socket, be a dialer or a server client, to be operated as a single handle that internally carries about the buffering for you. As one can see in the examples, compared to their "manual" alternatives they are very easy to use, ressembling Ecore_Con_Server/Ecore_Con_Client, but also offers line-based delimiters and the possibility to let the socket to handle queueing for you in case you received partial messages (just do not read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
lib/ecore_con/efl_net_socket_simple.c \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_socket_fd.c \
lib/ecore_con/efl_net_socket_tcp.c \
efl_net_dialer_udp: "connect" to an UDP server to send and receive data. Like existing ecore_con code, this does not use SOCKSv5 UDP proxy. It's kinda cumbersome to add since requires a keep alive TCP connection to the server, a second UDP channel and framing around the original UDP frame. Added UDP_CORK (if present) to match TCP_UDP present in TCP sockets, this allows one to execute multiple write() calls that will result in a single datagram, generated when CORK becomes FALSE again. The efl_io_copier_example.c now accepts this as output. There is no input UDP as there is no way to notify the server of a connection (since such thing doesn't exit), usually servers react after a datagram is received, replying to the source.
2016-10-18 13:51:59 -07:00
lib/ecore_con/efl_net_socket_udp.c \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_dialer.c \
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets. The low level I/O primitives are powerful but adds some complexity to use, for bi-directional streaming communication one ends creating two Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can operate. Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this will allow the socket, be a dialer or a server client, to be operated as a single handle that internally carries about the buffering for you. As one can see in the examples, compared to their "manual" alternatives they are very easy to use, ressembling Ecore_Con_Server/Ecore_Con_Client, but also offers line-based delimiters and the possibility to let the socket to handle queueing for you in case you received partial messages (just do not read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
lib/ecore_con/efl_net_dialer_simple.c \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_dialer_tcp.c \
efl_net_dialer_udp: "connect" to an UDP server to send and receive data. Like existing ecore_con code, this does not use SOCKSv5 UDP proxy. It's kinda cumbersome to add since requires a keep alive TCP connection to the server, a second UDP channel and framing around the original UDP frame. Added UDP_CORK (if present) to match TCP_UDP present in TCP sockets, this allows one to execute multiple write() calls that will result in a single datagram, generated when CORK becomes FALSE again. The efl_io_copier_example.c now accepts this as output. There is no input UDP as there is no way to notify the server of a connection (since such thing doesn't exit), usually servers react after a datagram is received, replying to the source.
2016-10-18 13:51:59 -07:00
lib/ecore_con/efl_net_dialer_udp.c \
WIP: efl.net: Introduce Efl.Net.Dialer.Http This class implements the Efl.Net.Dialer interface using libcurl to perform HTTP requests. That means it's an Efl.Net.Dialer, Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with Efl.Io.Copier as demonstrated in the efl_io_copier_example.c
2016-08-19 20:55:26 -07:00
lib/ecore_con/efl_net_dialer_http.c \
efl_net_dialer_websocket: EFL now does WebSocket! The Efl.Net.Dialer.Websocket is just like other Efl.Net.Dialers: you can dial, you can close, monitor connected/address resolved and so on. And you can use WebSocket primitives and events such as text_send(), binary_send(), ping() and close_request() (since WebSockets use a close process where you should state a close reason). See efl_net_dialer_websocket_example.c Even if WebSocket is a message-based protocol (like "packets" from UDP), you can use efl_net_dialer_websocket_streaming_mode_set() to tell it to handle text or binary messages as a stream. Then all the Efl.Io.Reader and Efl.Io.Writer APIs work as expected, see efl_io_copier_example.c updates.
2016-08-29 20:28:00 -07:00
lib/ecore_con/efl_net_dialer_websocket.c \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_server.c \
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets. The low level I/O primitives are powerful but adds some complexity to use, for bi-directional streaming communication one ends creating two Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can operate. Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this will allow the socket, be a dialer or a server client, to be operated as a single handle that internally carries about the buffering for you. As one can see in the examples, compared to their "manual" alternatives they are very easy to use, ressembling Ecore_Con_Server/Ecore_Con_Client, but also offers line-based delimiters and the possibility to let the socket to handle queueing for you in case you received partial messages (just do not read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
lib/ecore_con/efl_net_server_simple.c \
efl.net: socket, server and dialer for TCP. Efl.Net.Server defines how to accept new connections, doing the bind(), listen() and accept() for protocols such as TCP. Efl.Net.Dialer defines to to reach a server. Both are based on Efl.Net.Socket as communication interface that is based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being usable with code such as Efl.Io.Copier. The Server will emit an event "client,add" with the established Socket, which is a child and can be closed by both the server or the user. The Dialer extends the Socket and allows for creating one given an address, that will be resolved and connected. TCP is the initial implementation so we an validate the interfaces. UDP, Unix-Local and SSL will come later as derivate classes. The examples are documented and should cover the basic principles: - efl_io_copier_example can accept "tcp://IP:PORT" and will work as a "netcat", can send data from socket, file or stdin to a socket, file, stdout or stderr. - efl_net_server_example listens for connections and can either reply "Hello World!" and take some data or work as an echo-server, looping back all received data to the user. More complex interactions that require a "chat" between client and server will be covered with new classes later, such as a queue that empties itself once data is read.
2016-08-17 21:53:16 -07:00
lib/ecore_con/efl_net_server_fd.c \
ecore_con: add an intermediate Efl.Net.Server.Ip
2017-09-29 14:12:03 -07:00
lib/ecore_con/efl_net_server_ip.c \
efl_net_server_udp: initial UDP server. This is the initial UDP server that works similarly to the TCP one, however under the hood it's widely different since the socket is reused for all "clients", thus needs a new Efl.Net.Server.Udp.Client (Efl.Net.Socket) as Efl.Net.Socket.Udp exposes the fd and options such as 'cork', which would interfere in other clients. The main socket will read the packets and find an existing client to feed it. If no client exists, then it will create one if not overr limit. Since there is no kernel-queuing as done by listen()/accept(), the 'no reject' case will just accept the client anyway. Next commits will improve UDP server handling with some advanced features: - join multicast groups - bind to a specific interface (SO_BINDTODEVICE) - block packets going out of local network (SO_DONTROUTE) - specify priorities (SO_PRIORITY)
2016-10-21 08:24:02 -07:00
lib/ecore_con/efl_net_server_tcp.c \
lib/ecore_con/efl_net_server_udp.c \
efl_net_socket_ssl: initial SSL wrapper. This is the first step towards SSL connections on top of sockets, with an example on how to upgrade a dialer and a server client using TCP.
2016-10-28 17:48:19 -07:00
lib/ecore_con/efl_net_server_udp_client.c \
lib/ecore_con/efl_net_socket_ssl.c \
efl_net_{server,dialer}_ssl: TCP + SSL easy to use. in the previous commit we're manually upgrading an existing TCP socket to SSL. It is desired since some protocols need to negotiate, like STARTTLS and the likes Now we offer 2 classes that does autostart SSL once the socket is ready.
2016-10-31 20:31:56 -07:00
lib/ecore_con/efl_net_ssl_context.c \
lib/ecore_con/efl_net_dialer_ssl.c \
ecore_con: Ecore_Con_Server now on top of Efl_Net! This is a major work and unfortunately couldn't be split into smaller pieces as old code was highly coupled. Ecore_Con_Server is now a wrapper around Efl_Net_Dialer_Simple (ecore_con_server_connect()) and Efl_Net_Server_Simple (ecore_con_server_add()), doing all that the original version did with some fixes so ecore_con_ssl_server_upgrade() and ecore_con_ssl_client_upgrade() are more usable -- see the examples and -t/--type=tcp+ssl. I tried to be bug-compatible, with code annotations where things doesn't make sense. This was based on ecore_con_suite tests and some manual experimenting with the examples, these can be helpful if you find regressions (report/assign to me).
2016-12-07 07:34:28 -08:00
lib/ecore_con/efl_net_server_ssl.c \
efl_net: add Efl.Net.Ip_Address This is a string parser, serializer and asynchronous resolver. It's purpose is to convert to and from the strings we use in our dialers and servers, such as "127.0.0.1:1234" or "[::1]:1234", properties allow to check the family, port, address bytes (slice) and even get a struct sockaddr pointer to use with bind()/connect() in outside code. It will also offer some utilities present in netinet/in.h in an easy to use way, after all IN6_IS_ADDR_LOOPBACK() works one way, while there is no IN_LOOPBACK and comparing with INADDR_LOOPBACK will lead to errors since it's in network order. Last but not least, it will do asynchronous resolve of host and port names using an internal thread and getaddrinfo(). The results are delivered using a Future with an array of objects.
2016-12-11 20:23:29 -08:00
lib/ecore_con/ecore_con_local.c \
ecore: use new bs static lib
2018-02-16 11:37:17 -08:00
lib/ecore_con/efl_net_ip_address.c \
static_libs/buildsystem/buildsystem.h \
static_libs/buildsystem/buildsystem_autotools.c
efl_net_{control,session}: allow "none" backend. Since connman is specific to linux, on other platforms just compile a dummy "none" backend that will always report online and no other details. This will be used in Windows, MacOS and other platforms that still lack a proper backend. The compile-time infrastructure also allows for networkmanager to be added with ease, simply copy "efl_net*-none.c" or "efl_net*-connman.c" to be a starting point and then add its specifics, adapting configure.ac and Makefile_Ecore_Con.am
2016-11-18 12:11:51 -08:00
if EFL_NET_CONTROL_BACKEND_CONNMAN
lib_ecore_con_libecore_con_la_SOURCES += \
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
lib/ecore_con/efl_net-connman.h \
lib/ecore_con/efl_net-connman.c \
lib/ecore_con/efl_net_control_access_point-connman.c \
lib/ecore_con/efl_net_control_technology-connman.c \
lib/ecore_con/efl_net_control-connman.c \
lib/ecore_con/efl_net_session-connman.c
efl_net_{control,session}: allow "none" backend. Since connman is specific to linux, on other platforms just compile a dummy "none" backend that will always report online and no other details. This will be used in Windows, MacOS and other platforms that still lack a proper backend. The compile-time infrastructure also allows for networkmanager to be added with ease, simply copy "efl_net*-none.c" or "efl_net*-connman.c" to be a starting point and then add its specifics, adapting configure.ac and Makefile_Ecore_Con.am
2016-11-18 12:11:51 -08:00
endif
if EFL_NET_CONTROL_BACKEND_NONE
lib_ecore_con_libecore_con_la_SOURCES += \
lib/ecore_con/efl_net_control_access_point-none.c \
lib/ecore_con/efl_net_control_technology-none.c \
lib/ecore_con/efl_net_control-none.c \
lib/ecore_con/efl_net_session-none.c
endif
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
efl_net_socket_ssl: initial SSL wrapper. This is the first step towards SSL connections on top of sockets, with an example on how to upgrade a dialer and a server client using TCP.
2016-10-28 17:48:19 -07:00
# these are included rather than compiled out
# so the structures can be embedded into the
# object Private Data and allows functions to
# be all static
EXTRA_DIST2 += \
ecore-con: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in evas and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de> Differential Revision: https://phab.enlightenment.org/D8108
2019-03-05 14:00:37 -08:00
lib/ecore_con/ecore_con_eet_base_eo.c \
lib/ecore_con/ecore_con_eet_base_eo.legacy.c \
lib/ecore_con/ecore_con_eet_client_obj_eo.c \
lib/ecore_con/ecore_con_eet_server_obj_eo.c \
efl_net_socket_ssl: initial SSL wrapper. This is the first step towards SSL connections on top of sockets, with an example on how to upgrade a dialer and a server client using TCP.
2016-10-28 17:48:19 -07:00
lib/ecore_con/efl_net_ssl_conn-openssl.c \
lib/ecore_con/efl_net_ssl_conn-gnutls.c \
lib/ecore_con/efl_net_ssl_conn-none.c \
lib/ecore_con/efl_net_ssl_ctx-openssl.c \
lib/ecore_con/efl_net_ssl_ctx-gnutls.c \
lib/ecore_con/efl_net_ssl_ctx-none.c
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
if HAVE_WINDOWS
implement efl_net_{socket,dialer,server}_windows This is the local socket for windows, analogous to AF_UNIX. `Efl_Net_Socket_Windows` is the base class doing `ReadFile()` and `WriteFile()` using overlapped I/O, as well as the close procedure (`FlushFileBuffers()`, `DisconnectNamedPipe()` and `CloseHandle()`). These are done on top of an existing HANDLE that is set by `Efl_Net_Dialer_Windows` (from `CreateFile()`) or `Efl_Net_Server_Windows` (from `CreateNamedPipe()`). The overlapped I/O will return immediately, either with operation completed or `ERROR_IO_PENDING`, which means the kernel will execute that asynchronously and will later `SetEvent(overlapped.hEvent)` which is an event we wait on our main loop. That `overlapped` handle must exist during the call lifetime, thus cannot be bound to `pd`, as we may call `CancelIo()` but there is no guarantee the memory won't be touched, in that case we keep the overlapped around, but without an associated object. Windows provides no notification "can read without blocking" or non-blocking calls that returns partial data. The way to go is to use these overlapped I/O, with an initial `ReadFile()` to an internal buffer, once that operation finishes, we callback the user to says there is something to read (`efl_io_reader_can_read_set()`) and wait until `efl_io_reader_read()` is called to consume the available data, then `ReadFile()` is called again to read more data to the same internal buffer. Likewise, there is no "can write without blocking" or non-blocking calls that sends only partial data. The way to go is to get user bytes in `efl_io_writer_write()` and copy them in an internal buffer, then call `WriteFile()` on that and inform the user nothing else can be written until that operation completes (`efl_io_writer_can_write_set()`). This is cumbersome since we say we "sent" stuff when we actually didn't, it's still in our internal buffer (`pd->send.bytes`), but nonetheless the kernel and the other peer may be adding even more buffers, in this case we need to do a best effort to get it delivery. A particular case is troublesome: `write() -> close()`, this may result in `WriteFile()` pending, in this case we wait using `GetOverlappedResult()`, *this is nasty and may block*, but it's the only way I see to cope with such common use case. Other operations, like ongoing `ReadFile()` or `ConnectNamedPipe()` will be canceled using `CancelIo()`. Q: Why no I/O Completion Port (IOCP) was used? Why no CreateThreadpoolIo()? These perform much better! A: These will call back from secondary threads, but in EFL we must report back to the user in order to process incoming data or get more data to send. That is, we serialize everything to the main thread, making it impossible to use the benefits of IOCP and similar such as CreateThreadpoolIo(). Since we'd need to wakeup the main thread anyways, using `OVERLAPPED.hEvent` with `ecore_main_win32_handler_add()` does the job as we expect. Thanks to Vincent Torri (vtorri) for his help getting this code done with an example on how to do the NamedPipe handling on Windows.
2017-03-22 00:29:16 -07:00
lib_ecore_con_libecore_con_la_SOURCES += \
lib/ecore_con/efl_net_socket_windows.c \
lib/ecore_con/efl_net_dialer_windows.c \
lib/ecore_con/efl_net_server_windows.c
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
else
ecore_con: Ecore_Con_Server now on top of Efl_Net! This is a major work and unfortunately couldn't be split into smaller pieces as old code was highly coupled. Ecore_Con_Server is now a wrapper around Efl_Net_Dialer_Simple (ecore_con_server_connect()) and Efl_Net_Server_Simple (ecore_con_server_add()), doing all that the original version did with some fixes so ecore_con_ssl_server_upgrade() and ecore_con_ssl_client_upgrade() are more usable -- see the examples and -t/--type=tcp+ssl. I tried to be bug-compatible, with code annotations where things doesn't make sense. This was based on ecore_con_suite tests and some manual experimenting with the examples, these can be helpful if you find regressions (report/assign to me).
2016-12-07 07:34:28 -08:00
lib_ecore_con_libecore_con_la_SOURCES += \
addded efl_net_{socket,dialer,server}_unix This introduces AF_UNIX server and dialer, these are not available on Windows as in that platform we'll create a custom class for native 'local' communication. In the future we can add a wrapper class Efl.Net.Local that will use the class for each platform, but won't expose its details. For instance, if we ever expose 'credentials' (which I didn't because they are not portable), then it doesn't make sense to try to match that on Windows. The 'Efl.Net.Local' would just stick to the basics: Reader, Writer and Closer APIs.
2016-10-26 13:57:37 -07:00
lib/ecore_con/efl_net_socket_unix.c \
lib/ecore_con/efl_net_dialer_unix.c \
lib/ecore_con/efl_net_server_unix.c
merge: add escape ecore, fix several bugs SVN revision: 79995
2012-12-02 14:35:45 -08:00
endif
ecore_con - move libproxy to a slave binary with stdin/out msging so here's the ugly problem. libproxy. yes. we've discussed memory usage (e.g. it may have to execute javascript and pull in lots of deps etc.) but we dlopene'd on the fly. ok... but this didn't solve another issue i hit: libproxy was causing enlightenment to abort(). some internal bit of libproxy was raising a c++ exception. this wasn't caught. this causes an abort(). takes down your entire desktop. FANTASTIC. this is bad. i wouldnt' expect a library we depend on to be THIS anti-social but libproxy seemingly is. it SHOULd catch its error sand just propagate back to us so we can handle gracefully. there reall is no way around this - isolate libproxy. it's even worse that libproxy can load arbitrary modules that come from anywhere sho who knows what issues this can cause. isolation is the best solution i can think of. so this makes an elf+net_proxy_helper we spawn the first time we need a proxy lookup. we re-use that binary again and again until it exits (it should exit after 10 seconds of being idle with no requests coming in/pending). it'll respawn again later if needed. this involves now the efl net threads having to marshall back to mainloop to do the spawn and to write to the proxy process (reading is done by async exe data events and the data is passed down a thread queue to the waitng efl net thread). if the exe dies with pending requests unanswered then it's respawned again and the req's are re-sent to it... just in case. it has a limit on how often it'll respawn quickly. this seems to work in my limited testing. this ALSO now isolates memory usage of libproxy to another slave process AND this process will die taking its memory with it once it's been idle for long enough. that;s also another good solution to keeping libproxy impact at bay.
2017-01-08 05:57:54 -08:00
lib_ecore_con_libecore_con_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
-DPACKAGE_DATA_DIR=\"$(datadir)/ecore\" \
-DPACKAGE_BUILD_DIR=\"$(abs_top_builddir)\" \
ecore: use new bs static lib
2018-02-16 11:37:17 -08:00
-DPACKAGE_SRC_DIR=\"$(abs_top_srcdir)\" \
Windows : fix the definition of EAPI Summary: with autotools, EFL_BUILD was passed to the preprocessor for libraries and binaries, which was wrong. Only libraries must have EFL_BUILD defined. See T7797 for an explanation This also fix EAPI in Ecore_Getopt.g and Efl_UI.h Also note that all the wayland and drm Makefile's have not been touched Test Plan: compilation Reviewers: raster, zmike, cedric Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8602
2019-04-15 03:53:42 -07:00
-DEFL_BUILD \
ecore_con - move libproxy to a slave binary with stdin/out msging so here's the ugly problem. libproxy. yes. we've discussed memory usage (e.g. it may have to execute javascript and pull in lots of deps etc.) but we dlopene'd on the fly. ok... but this didn't solve another issue i hit: libproxy was causing enlightenment to abort(). some internal bit of libproxy was raising a c++ exception. this wasn't caught. this causes an abort(). takes down your entire desktop. FANTASTIC. this is bad. i wouldnt' expect a library we depend on to be THIS anti-social but libproxy seemingly is. it SHOULd catch its error sand just propagate back to us so we can handle gracefully. there reall is no way around this - isolate libproxy. it's even worse that libproxy can load arbitrary modules that come from anywhere sho who knows what issues this can cause. isolation is the best solution i can think of. so this makes an elf+net_proxy_helper we spawn the first time we need a proxy lookup. we re-use that binary again and again until it exits (it should exit after 10 seconds of being idle with no requests coming in/pending). it'll respawn again later if needed. this involves now the efl net threads having to marshall back to mainloop to do the spawn and to write to the proxy process (reading is done by async exe data events and the data is passed down a thread queue to the waitng efl net thread). if the exe dies with pending requests unanswered then it's respawned again and the req's are re-sent to it... just in case. it has a limit on how often it'll respawn quickly. this seems to work in my limited testing. this ALSO now isolates memory usage of libproxy to another slave process AND this process will die taking its memory with it once it's been idle for long enough. that;s also another good solution to keeping libproxy impact at bay.
2017-01-08 05:57:54 -08:00
@ECORE_CON_CFLAGS@
Win32: Add configuration to cross-compile Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
2014-05-15 19:26:53 -07:00
lib_ecore_con_libecore_con_la_LIBADD = @ECORE_CON_LIBS@ @EVIL_LIBS@
efl: simplify automake. Instead of -I$(top_srcdir)... -I$(top_builddir)... and then do it for the .la, use the EFL_ macros to generate the contents to be used in automake files. There is a nasty bit that libtool will parse Makefile*.am and will not get _DEPENDENCIES from _LIBADD and _LDADD if these are in @REPLACEMENT@. To solve this we must explicitly set _DEPENDENCIES. The contents of this is almost the same as _LIBADD or _LDADD with the "_INTERNAL_" replacement name. I hope the code will be result will be shorter and consistent as there is less places to change when we add/remove dependencies. Statistics are quite impressive (diffstat): {{{ 37 files changed, 663 insertions(+), 1599 deletions(-) }}} SVN revision: 82785
2013-01-14 14:36:23 -08:00
lib_ecore_con_libecore_con_la_DEPENDENCIES = @ECORE_CON_INTERNAL_LIBS@
efl: unify LDFLAGS for LTLIBRARIES SVN revision: 81911
2012-12-30 14:15:29 -08:00
lib_ecore_con_libecore_con_la_LDFLAGS = @EFL_LTLIBRARY_FLAGS@
elua/autotools: generate .eo.lua files out of all eo files at build time Also change the generator a bit so that it doesn't rely on lib name information and fix the runtime to properly source lua files within tree.
2014-10-06 03:32:25 -07:00
ecore_con: add http_parser static lib. Summary: This lib would be used in efl_network_websocket. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric Reviewed By: cedric Differential Revision: https://phab.enlightenment.org/D3244 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-11-09 15:52:11 -08:00
lib_ecore_con_libecore_con_la_CPPFLAGS += -I$(top_srcdir)/src/static_libs/http-parser
build: split EXTRA_DIST files in src/ off from DISTFILES and handle separately This is again to avoid the "Argument list too long" error we are hitting more and more now. Given we just merged elementary, emotion generic players, evas generic loaders and elm_code it is not surprising we are hitting it again. This time the number of files being hold in DISTFILES has just grown to big so a make dist was no longer possible. If one looks at what the DISTFILES variable from automake holds you can image it grows a lot with all the source files plus generated files we have in tree now. DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) To cut off a big chunk but still keep all the other automagic in place for SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle the files in a dist-hook now. Another thing to note here is that this also only happens as we have the one big Makefile with includes. If we go back to per directory Makefiles this problem should vanish as well. In any case we need a solution for 1.18 now and this is what I have to offer. If you have a cleaner solution in mind feel welcome to test it out and if everything we need keeps working (make, make examples, make check, make benchmark, make dist and make distcheck) go ahead.
2016-06-08 01:26:06 -07:00
EXTRA_DIST2 += \
ecore_con: Make sure the server.key and pem are distributed in the tarball Pull them out of the if EFL_ENABLE_TESTS test as we need them to be put into the tarball in all cases.
2015-04-07 04:17:25 -07:00
tests/ecore_con/server.key \
ecore_con: add http_parser static lib. Summary: This lib would be used in efl_network_websocket. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric Reviewed By: cedric Differential Revision: https://phab.enlightenment.org/D3244 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-11-09 15:52:11 -08:00
tests/ecore_con/server.pem \
static_libs/http-parser/AUTHORS \
static_libs/http-parser/CONTRIBUTIONS \
static_libs/http-parser/README.md \
static_libs/http-parser/test.c \
static_libs/http-parser/contrib/parsertrace.c \
static_libs/http-parser/contrib/url_parser.c
ecore_con: Make sure the server.key and pem are distributed in the tarball Pull them out of the if EFL_ENABLE_TESTS test as we need them to be put into the tarball in all cases.
2015-04-07 04:17:25 -07:00
ecore_con - move libproxy to a slave binary with stdin/out msging so here's the ugly problem. libproxy. yes. we've discussed memory usage (e.g. it may have to execute javascript and pull in lots of deps etc.) but we dlopene'd on the fly. ok... but this didn't solve another issue i hit: libproxy was causing enlightenment to abort(). some internal bit of libproxy was raising a c++ exception. this wasn't caught. this causes an abort(). takes down your entire desktop. FANTASTIC. this is bad. i wouldnt' expect a library we depend on to be THIS anti-social but libproxy seemingly is. it SHOULd catch its error sand just propagate back to us so we can handle gracefully. there reall is no way around this - isolate libproxy. it's even worse that libproxy can load arbitrary modules that come from anywhere sho who knows what issues this can cause. isolation is the best solution i can think of. so this makes an elf+net_proxy_helper we spawn the first time we need a proxy lookup. we re-use that binary again and again until it exits (it should exit after 10 seconds of being idle with no requests coming in/pending). it'll respawn again later if needed. this involves now the efl net threads having to marshall back to mainloop to do the spawn and to write to the proxy process (reading is done by async exe data events and the data is passed down a thread queue to the waitng efl net thread). if the exe dies with pending requests unanswered then it's respawned again and the req's are re-sent to it... just in case. it has a limit on how often it'll respawn quickly. this seems to work in my limited testing. this ALSO now isolates memory usage of libproxy to another slave process AND this process will die taking its memory with it once it's been idle for long enough. that;s also another good solution to keeping libproxy impact at bay.
2017-01-08 05:57:54 -08:00
### Binary
proxyhelperdir = \
$(libdir)/ecore_con/utils/$(MODULE_ARCH)
proxyhelper_PROGRAMS = bin/ecore_con/efl_net_proxy_helper
bin_ecore_con_efl_net_proxy_helper_SOURCES = \
bin/ecore_con/efl_net_proxy_helper.c
bin_ecore_con_efl_net_proxy_helper_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
-DPACKAGE_DATA_DIR=\"$(datadir)/ecore\" \
@EINA_CFLAGS@
bin_ecore_con_efl_net_proxy_helper_LDADD = @USE_EINA_LIBS@
net_proxy_helper: fix typo in dependencies Fixes: error: cannot find the library 'lib/eina/libeina.la' or unhandled argument 'lib/eina/libeina.la' Signed-off-by: Romain Naour <romain.naour@gmail.com>
2017-02-09 14:42:14 -08:00
bin_ecore_con_efl_net_proxy_helper_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
ecore_con - move libproxy to a slave binary with stdin/out msging so here's the ugly problem. libproxy. yes. we've discussed memory usage (e.g. it may have to execute javascript and pull in lots of deps etc.) but we dlopene'd on the fly. ok... but this didn't solve another issue i hit: libproxy was causing enlightenment to abort(). some internal bit of libproxy was raising a c++ exception. this wasn't caught. this causes an abort(). takes down your entire desktop. FANTASTIC. this is bad. i wouldnt' expect a library we depend on to be THIS anti-social but libproxy seemingly is. it SHOULd catch its error sand just propagate back to us so we can handle gracefully. there reall is no way around this - isolate libproxy. it's even worse that libproxy can load arbitrary modules that come from anywhere sho who knows what issues this can cause. isolation is the best solution i can think of. so this makes an elf+net_proxy_helper we spawn the first time we need a proxy lookup. we re-use that binary again and again until it exits (it should exit after 10 seconds of being idle with no requests coming in/pending). it'll respawn again later if needed. this involves now the efl net threads having to marshall back to mainloop to do the spawn and to write to the proxy process (reading is done by async exe data events and the data is passed down a thread queue to the waitng efl net thread). if the exe dies with pending requests unanswered then it's respawned again and the req's are re-sent to it... just in case. it has a limit on how often it'll respawn quickly. this seems to work in my limited testing. this ALSO now isolates memory usage of libproxy to another slave process AND this process will die taking its memory with it once it's been idle for long enough. that;s also another good solution to keeping libproxy impact at bay.
2017-01-08 05:57:54 -08:00
ecore_con: Split ecore_con test suite from ecore. Summary: Have created ecore_con test suite. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric, Sergeant_Whitespace, stefan_schmidt Subscribers: stefan_schmidt, Sergeant_Whitespace, cedric Maniphest Tasks: T2235 Differential Revision: https://phab.enlightenment.org/D2269
2015-04-06 06:59:10 -07:00
### Unit tests
if EFL_ENABLE_TESTS
check_PROGRAMS += tests/ecore_con/ecore_con_suite
TESTS += tests/ecore_con/ecore_con_suite
tests_ecore_con_ecore_con_suite_SOURCES = \
tests/ecore_con/ecore_con_suite.c \
tests/ecore_con/ecore_con_test_ecore_con.c \
tests/ecore_con/ecore_con_test_ecore_con_url.c \
ecore_con: add test cases for ecore_con_eet. Summary: Added test case for ecore_con_eet. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D2347 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-04-15 05:50:03 -07:00
tests/ecore_con/ecore_con_test_ecore_con_eet.c \
efl_net: add Efl.Net.Ip_Address This is a string parser, serializer and asynchronous resolver. It's purpose is to convert to and from the strings we use in our dialers and servers, such as "127.0.0.1:1234" or "[::1]:1234", properties allow to check the family, port, address bytes (slice) and even get a struct sockaddr pointer to use with bind()/connect() in outside code. It will also offer some utilities present in netinet/in.h in an easy to use way, after all IN6_IS_ADDR_LOOPBACK() works one way, while there is no IN_LOOPBACK and comparing with INADDR_LOOPBACK will lead to errors since it's in network order. Last but not least, it will do asynchronous resolve of host and port names using an internal thread and getaddrinfo(). The results are delivered using a Future with an array of objects.
2016-12-11 20:23:29 -08:00
tests/ecore_con/ecore_con_test_efl_net_ip_address.c \
ecore_con: Split ecore_con test suite from ecore. Summary: Have created ecore_con test suite. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric, Sergeant_Whitespace, stefan_schmidt Subscribers: stefan_schmidt, Sergeant_Whitespace, cedric Maniphest Tasks: T2235 Differential Revision: https://phab.enlightenment.org/D2269
2015-04-06 06:59:10 -07:00
tests/ecore_con/ecore_con_suite.h
tests_ecore_con_ecore_con_suite_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
build: define PACKAGE_BUILD_DIR as $(abs_top_builddir) for all test suites Summary: this needs to be consistent so that it can be used reliably across suites also these build flags really need to be consolidated into a single variable that can be reused Depends on D6666 Reviewers: devilhorns, bu5hm4n Reviewed By: bu5hm4n Subscribers: bu5hm4n, cedric, #committers Tags: #efl_build Differential Revision: https://phab.enlightenment.org/D6731
2018-08-08 06:45:30 -07:00
-DPACKAGE_BUILD_DIR=\"$(abs_top_builddir)\" \
ecore_con: Split ecore_con test suite from ecore. Summary: Have created ecore_con test suite. Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com> Reviewers: cedric, Sergeant_Whitespace, stefan_schmidt Subscribers: stefan_schmidt, Sergeant_Whitespace, cedric Maniphest Tasks: T2235 Differential Revision: https://phab.enlightenment.org/D2269
2015-04-06 06:59:10 -07:00
-DTESTS_SRC_DIR=\"$(top_srcdir)/src/tests/ecore_con\" \
-DTESTS_BUILD_DIR=\"$(top_builddir)/src/tests/ecore_con\" \
@CHECK_CFLAGS@ \
@ECORE_CFLAGS@ \
@ECORE_CON_CFLAGS@
tests_ecore_con_ecore_con_suite_LDADD = \
@CHECK_LIBS@ \
@USE_ECORE_LIBS@ \
@USE_ECORE_CON_LIBS@
tests_ecore_con_ecore_con_suite_DEPENDENCIES = \
@USE_ECORE_INTERNAL_LIBS@ \
@USE_ECORE_CON_INTERNAL_LIBS@
endif
build: disable Lua binding generation Summary: As Lua bindings don't work right now, it is pointless to waste build time generating them. Elua itself on the other hand is useful and should stay enabled. This also does some preparation work for separate configure switch for bindings after release, but for now keep configure switches as they are. Reviewers: zmike, stefan_schmidt Subscribers: cedric, bu5hm4n, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D6721
2018-08-01 10:31:15 -07:00
if HAVE_LUA_BINDINGS
elua/autotools: generate .eo.lua files out of all eo files at build time Also change the generator a bit so that it doesn't rely on lib name information and fix the runtime to properly source lua files within tree.
2014-10-06 03:32:25 -07:00
ecore_con_eolian_lua = $(ecore_con_eolian_files:%.eo=%.eo.lua)
generated_ecore_con_lua_all = $(ecore_con_eolian_lua)
build: clean generated js and lua files manually to avoid problems with CLEANFILES We hit another argument too long error with CLEANFILES. Moving the generated files for js and lua into separated variables and cleaning them manually fixes the issue.
2016-06-21 07:13:17 -07:00
GENERATED_LUA_BINDINGS += $(generated_ecore_con_lua_all)
elua/autotools: generate .eo.lua files out of all eo files at build time Also change the generator a bit so that it doesn't rely on lib name information and fix the runtime to properly source lua files within tree.
2014-10-06 03:32:25 -07:00
installed_ecoreconluadir = $(datadir)/elua/modules/ecore_con
nodist_installed_ecoreconlua_DATA = $(generated_ecore_con_lua_all)
endif
efl-js: JavaScript Eolian binding To configure efl sources with bindings to use in nodejs add ––with-js=nodejs in configure flags to generate node files $ configure --with-js=nodejs and compile normally with: $ make $ make install To use, you have to require efl: efl = require('efl') The bindings is divided in two parts: generated and manually written. The generation uses the Eolian library for parsing Eo files and generate C++ code that is compiled against V8 interpreter library to create a efl.node file that can be required in a node.js instance. @feature
2014-09-01 11:08:49 -07:00
if HAVE_JS
generated_ecore_con_js_bindings = $(ecore_con_eolian_files:%.eo=%.eo.js.cc)
GENERATED_JS_BINDINGS += $(generated_ecore_con_js_bindings)
endif