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? > 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
