On Sun, Nov 2, 2008 at 11:53 PM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Sat, 4 Oct 2008 23:27:33 -0400 "Matt Barclay" <[EMAIL PROTECTED]> babbled: > > hmm - you know what might have been cleaner... on data in get a CLIENT_ADD > event and literally add a client then instantly post data from that client in > a > CLIENT_DATA and then a CLIENT_DEL immediately after. it sounds a big heavy > BUT... it's clean. > > 1. it looks just like tcp/unix socket connections except the connection is > only > alive for 1 packet (lump of data). > 2. it solves your ability to preserve client info and all calls works just as > if it were tcp or unix socket. you know just where to send the data back to as > u have a client handle. :) > 3. it's clean > > what do you think?
I like it, thanks for the feedback! I'm traveling early this week, but I will have a look on Wednesday. I'll keep an eye on the list in case someone beats me to it. Regards, Matt >> 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/ >> >> Regards, >> Matt >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] > > ------------------------------------------------------------------------- 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
