for data i use this: key= <pic ip number>_<fragment> lock key = <pic ip number>_lock
>Then there's no locking, and multiple PIC's can use memcached in parallel? yes many pic's in parallel and a app at server side read in multiget all data :) >That sounds like a win/win to me, if gross :) what's win/win ? hehehe 2011/2/5 dormando <[email protected]>: >> pic use memcache as a RAM memory >> first i lock memcache (with my today lock function) >> set a key to 0 >> i read data from pic, and put at memcache >> after 128 writes i put a sum (save this sum at pic internal memory) >> total bytes is about 1MB(1048576 bytes) (pic don't have this memory, >> it's a ADC read 2Bytes/read) >> after all 1MB sent, i check all sums with my internal memory, to make >> sure some data wasn't lost >> if lost, i start a new lock >> set a key to 1 >> after it, i unlock memcache (my today unlock function) >> wait just some minutes >> if get set isn't 2 return to first lock >> if 2 continue with another function inside pic program >> >> after key=1 my server (another app), process and set key to 2 if ok >> i'm using memcache as a key-value and as a server-client protocol >> ok it's not fast, but it's work >> the other implementation use a server side, and a ARM client side >> server don't use more memcache, ARM doesn't use it too, i'm using >> mysql at ARM side and tcp/ip socket to contact my app about new data >> (it's faster than a table update in mysql) > > Ah okay, this is actually perfect for gearmand, but I don't think you'll > have much fun writing your own client for it. > > If you would go for gearmand, you would: > > - send open packet to gearmand > - write/sum your data > - bail the connection if you get an error and try again > - if all data sent, all is good > - you can either use async job, or sync job and wait for a worker process > on the server to pick up the job and read it > ^ but as I said writing a gearmand client and figuring out how to write a > worker is more work. > > in your case, perhaps you could consider using a key prefix for your PIC > army? > > The dumbest/quickest thing I can think of: > > - assign each PIC a unique client id number > - make sure the server knows the list of ids > - each PIC will write to keys named: "key_IDNUMBER" (ie if the PIC's ID is > 5, it writes to "key_5" > - the server issues a large multiget to memcached asking for all of the > PIC ids, and processes any that it gets back (get key_1 key_2 key_3 etc) > > Then there's no locking, and multiple PIC's can use memcached in parallel? > That sounds like a win/win to me, if gross :) > > -Dormando > -- Roberto Spadim Spadim Technology / SPAEmpresarial
