On Sun, Oct 5, 2008 at 3:46 PM, Gustavo Sverzut Barbieri
<[EMAIL PROTECTED]> wrote:
> 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.
It meet the current code standard of ecore_con.
> 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.
As Arnaud is working on adding IPv6 support to ecore_con, more change
and cleanup are coming into it. So I don't think it's needed to put
this patch on hold, as change will come step by step inside ecore_con.
And if anything is broken, we will just fix it.
> One thing I noticed is that you leave trailing whitespaces on some
> lines, remove them before committing.
Yep, I removed them before committing the patch in svn.
--
Cedric BAIL
-------------------------------------------------------------------------
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
