7 messages in net.java.dev.spots.devRe: Persistent storage accessible by ...| From | Sent On | Attachments |
|---|---|---|
| Pete St. Pierre | Oct 14, 2008 11:22 am | |
| Eric Arseneau | Oct 14, 2008 11:27 am | |
| John Daniels | Oct 14, 2008 11:37 am | |
| Eric Arseneau | Oct 14, 2008 11:45 am | |
| Pete St. Pierre | Oct 14, 2008 11:55 am | |
| Ron Goldman | Oct 14, 2008 1:44 pm | |
| Pete St. Pierre | Oct 14, 2008 1:51 pm |
| Subject: | Re: Persistent storage accessible by basestation | |
|---|---|---|
| From: | Ron Goldman (Ron....@sun.com) | |
| Date: | Oct 14, 2008 1:44:28 pm | |
| List: | net.java.dev.spots.dev | |
Having the host app (or shared basestation manager) read the routing table and pass it to the basestation SPOT seems a good solution. However, how will the static routing manager enable a free-range SPOT to communicate with a host app (including spotclient)? The host app's address is generated dynamically, so how does it get included in the previously written static routing tables on the free-range SPOTs? Maybe there needs to be a way to say all addresses whose high 32 bits match are routed through basestation x? Of course this gets broken if the host gets its address assigned dynamically....
Also I don't feel comfortable with the routing table being part of a SPOT app. What table is used if I try to run two apps on the same SPOT? Shouldn't the routing table be associated with the SPOT itself & be used by all apps deployed to the SPOT?
-- Ron --
p.s. what I do is take the size of the address string and fill in whatever is not needed, so 1 => 0014.4F01.0000.0001, 30A => 0014.4F01.0000.030A, 1.2345 => 0014.4F01.0001.2345 & 0A94.C69D. 0000.DB1C => 0A94.C69D.0000.DB1C.
On Oct 14, 2008, at 11:22 AM, Pete St. Pierre wrote:
Also, since size may be an issue, Ron has proposed shortening this file by eliding the common 48 high bits. While this may limit us when we ship SunSPOT # 0001.0000, it does cut the file size by 75%. A compromise may be to elide the high 32 bits.