DOT describes the "data-oriented transfer" service. The idea here is to separate the data transfer, and stick another layer in our fat protocol stack. It's really heavily related to my class project, actually. Lots of the same issues, more people trying to get practical value out of the DHT work.
I'm not totally sold on loving or hating it. It seems completely unreasonable, but I'm not sure I can put my finger on why. It doesn't optimize the common case, as they point out. Flexibility is nice, but only when you are solving a problem. They are not solving a problem really, rather just trying to allow for a design space where there currently isn't one. This means a system like this will never be used, but it doesn't mean it's bad work.
I should note, that one metric for success the authors had is that the SMTP client they build was robust enough for one of the two authors to use. I'm sold.
I do agree that this is more elegant. That may be the fact that I'm currently implementing a system with a lot of parallels to this. I think my biases will be laid bare in class.
In conclusion, this paper may be an argument as to why my yelling about metrics last class was wrong.
2 comments:
Again, is this stuff part of the networking stack, or does it belong at a "higher level"?
Well, if this was reasonable it's clearly part of the stack. The network layering structure has given us a huge design space, allowing for umpteen silly ideas to be implemented. We just need to recognize what's being optimized for in the real world, and then only break from that optimization when solving a real problem. Otherwise you're just spinning your wheels.
Post a Comment