Re: DIME Use Case?
David Buksbaum <[email protected]> Sun, 14 Apr 2002 11:14:54 -0400
| Newsgroups | gmane.comp.windows.devel.dime |
|---|---|
| Message-ID | <000801c1e3c7$2509f090$6401a8c0@scrooge> |
We did do performance analysis against SOAP over HTTP and SOAP over SMTP. In both cases, we were able to get a significant performance boost with SOAP over DIME. The are where the gains were made had little to do with MIME though. They had to do with connection startup and handshaking, and pulling the block off the wire on the other side. Some of the benefits of DIME is that it is not request response. It is a simple packet that encapsulates data. HTTP is request response, and the direction of data is often fixed. Using SOAP over DIME allowed us to do request, response, and events over the same pipe without any 'tricks' or complexity. As far as not implementing the chunked protocol, it is not much more difficult to do. Some others that I have given the code do have added it. We did not. It would not take much effort, but it serves no purpose for us at this time so we wont do it yet. Someday we will. >From my point of view, DIME is a replacement for HTTP and SMTP more so than for MIME. If I remember the spec correctly, DIME was designed with transporting MIME types, so I am not sure where the DIME vs. MIME has come up from. We don't use MIME because we don't need it, not because DIME was faster or better. We use DIME because it was faster and easier than HTTP and SMTP. David -----Original Message----- From: Discussion of DIME technology [mailto:[email protected]] On Behalf Of Eric Rescorla Sent: Sunday, April 14, 2002 10:57 AM To: [email protected] Subject: Re: [DIME] DIME Use Case? David Buksbaum <[email protected]> writes: > Bottom line is that it was easy to implement, it is fast (relative to > other wire schemes), Hmm... Define "fast". Have you done any performance analysis, comparing it to alternatives? > One caveat is that we did not implement the chunking protocol yet > since our payload sizes are somewhat small. It's almost always easy to hack up some custom protocol for a small application. When one is designing a standard protocol for general use, things rapidly become more complicated. I'm not saying that MIME couldn't be simpler--it could be. However, what I don't believe is that by the time you've produced a sufficiently complete version of DIME that it can displace MIME entirely (even for the limited environment in which you envision deploying DIME) the it will be sufficiently simpler than MIME to justify the additional specification effort. -Ekr -- [Eric Rescorla [email protected]] http://www.rtfm.com/