On Sun, Oct 5, 2008 at 12:27 AM, Matt Barclay <[EMAIL PROTECTED]> wrote:
> Hello,
>
> With this patch, ecore will have full UDP client/server support.
> Tooling UDP into the framework wasn't the easiest thing in the world
> because a UDP server has a single socket (i.e. file handle) that is
> used to handle all clients, whereas a TCP server generates a new
> socket for each client that encapsulates all the details of the
> connection. So here's how I implemented it:
>
> UDP Server (Unicast and Multicast):
> 1. When there is data on the socket, the callback uses recvfrom() to
> read the datagram and client address (struct sockaddr_in)
> 2. Create a new Ecore_Con_Client and save the client address
> (sockaddr_in) details with the "data" field. Leave the "fd", "buf",
> and "fd_handler" fields NULL.
> 3. Create a new Ecore_Con_Event_Client_Data and save the datagram in
> the "data" field, and the client in the "client" field
> 4. ecore_con_client_send() is updated to check for a
> client->server->type of ECORE_CON_REMOTE_UDP and use sendto() with
> client->data as the destination instead of appending the buffer to
> client->buf
> 5. relevant portions of ecore_con_client_del() and
> _ecore_con_event_client_data_free() are updated to ensure the client
> and data memory are freed
>
> The use of recvfrom() and sendto() feels a little dirty to me, but I'm
> not sure how else to preserve the client address so that packets can
> be sent back to the client. AFAIK, there isn't any way to do an
> accept() on a UDP socket such that a new file handle is created that
> encapsulates the end points of the UDP socket. Would appreciate some
> "enlightenment" on this topic if I'm wrong. ;)
>
> UDP Client support fits nicely into the framework as a new socket is
> created each time ecore_con_server_connect() is called.
>
> A UDP Server example program is included with the patch, and examples
> of multicast and UDP client support can be found in SVN:
> TEST/orig/ecore/
Looks good, but it was just an overview of the code, maybe someone
will reply with more in-depth comments.
As your complaing about recvfrom() and sendto(), I don't see any issue
with that, udp requires us to do so. The best thing to do is to to
make the ecore_con operate on callbacks ("virtuals") and have
different implementations for each system, then you just have the
"ifs" on the entry point, where you select the connection type, there
you set the function pointers and use them directly next times.
One thing I noticed is that you leave trailing whitespaces on some
lines, remove them before committing.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
