I think the next big thing is going to be HIP networks where Jini could excel as a communications platform via service discovery and the other parts of the platform that make it fast and easy to put together remote communications.
Gregg > On Feb 21, 2015, at 9:22 PM, Peter <j...@zeus.net.au> wrote: > > ----- Original message ----- >> >> Yes, “accidental” DOS certainly could apply, which is why I say that >> simple measures (like limiting the number of bytes that >> PreferredClassLoader will download before giving up) are a good idea. >> But I think that any radical re-imagining of object serialization is >> outside the scope of the River project. > > Ok, I'll bite, the work I've done doesn't fit into the radical re-imagining > category by any stretch, it uses the existing ObjectInputStream public api > and the public serial form of existing objects. It does however allow people > to implement an additional constructor by declaring an annotation, so they > can check invariants. These invariant checks won't be performed by the > standard ObjectInputStream, but the classes are compatible with either. > > My implementation also significantly outperforms java's standard > ObjectInputStream, reflectively calling one constructor is more performant > than reflectively setting every field in each class of an Object's hierarchy. > > I've decided I'll work on this on github, where interested parties can > participate if they want. > > > >> >> Cheers, >> >> Greg Trasuk >> >> On Feb 19, 2015, at 11:39 AM, Patricia Shanahan <p...@acm.org> wrote: >> >>> I generally agree, but do have a question. >>> >>> In other contexts, I've seen unintentional bugs, rather than >>> deliberate DOS, lead to behavior similar to DOS. A program goes wrong, >>> and tries to e.g. allocate far too much memory, or goes into a loop. >>> In contexts where that can happen, work to protect against DOS also >>> makes the software more robust. >>> >>> In shared service situations, an apparently non-critical program can >>> cause a DOS that also affects more important programs. Either all >>> programs have to be designed, reviewed, and tested to the reliability >>> requirements of the most sensitive program with which they share >>> resources, or there has to be isolation between them. >>> >>> Does this sort of consideration apply in reality to River? >>> >>> On 2/19/2015 6:58 AM, Greg Trasuk wrote: >>>> >>>> The type of issues you’re talking about seem to be centred on putting >>>> Jini services on the open internet, and allowing untrusted, unknown >>>> clients to access those services safely. >>>> >>>> Personally, my interest is more along the lines of Jini’s original >>>> goal, which was LAN-scoped or datacenter-scoped SOA. Further, I use >>>> it on more controlled networks. As far as I’m concerned, only code >>>> that I trust gets on the network. In a larger corporate scenario, I >>>> might lock down access to Reggie, but beyond that, I don’t consider >>>> DOS a threat. I think it would make sense to be able to put a byte >>>> limit on the stream used to load the class, and possibly a time >>>> limit, but beyond that, I think you’re adding complexity that isn’t >>>> needed. If you want to put a service on the web, use RESTful >>>> services, not Jini. I’m sure there’s a discoverability tool out >>>> there, if needed, but typically it isn’t. >>>> >>>> Also, since object serialization is not specific to River, I wonder >>>> if there’s a better forum for these kinds of deep discussions. I >>>> think it makes River look far harder than it is. >>>> >>>> Cheers, >>>> >>>> Greg Trasuk. >>>> >>>> On Feb 19, 2015, at 9:03 AM, Peter <j...@zeus.net.au> wrote: >>>> >>>>> What are your thoughts on security? >>>>> >>>>> Is it important to you? Is it important for River? >>>>> >>>>> Regards, >>>>> >>>>> Peter. >>>> >> >
