• Feeds

    Subscribe in a reader

  • Ads

Request/Reply and SMTP

Sunday, November 13 2005 - blog

Heh.Mark Barker noticed that mySMTP transport implementation also supports request/reply MEP’s andcomments (in his usually contrarian fashion) that SMTPwas one-way for a reason.

Layering two-way communication over a fundamentally one-way transports is areally common pattern. People do this all the time over SMTP – the numberof mails in my inbox that have subjects starting with “RE:” istestament to that.

Request/reply is a very useful (and prevalent) abstraction. Most applications(including HTTP) are built on a request/reply pattern. Sending a message,receiving a response, and being able to match up the request with the responsein some way is a useful thing. The problem with request/reply is that it often assumesa degree of temporal coupling that doesn’t strictly have to exist.

What do I mean by temporal coupling? It’s the assumptions you make abouthow long it will be before you get the response back. A lot of R/R is done overthe backchannel of a duplex transport like TCP – which couples thetimeliness of the response to the lifetime of the connection that sent theoriginal message. When we think about request/response as a MEP we oftenimplicitly assume “request/response in a reasonably small amount of time”.However, from a MEP perspective, request/response is still request/responseeven if the response comes hours or days later over a completely separatenetwork connection.

To be fair, most networking stacks (including Indigo, at the moment) don’texactly address this issue of temporal coupling because they maintaincorrelation state in memory. All the goo that’s used to match upresponses with requests is stored in-process, which couples the timeliness ofthe request to the lifetime of the currently executing process. Furthermore, alot of apps call request/response MEP’s using the local metaphor ofsynchronous method invocation. This pattern effectively ties up a bunch ofapp-level correlation state and stores it in the callstack of the thread thatsent the request – implying that the same thread must hang around untilthe response comes back. This puts a drain on system resources and decreasesoverall scalability. As a result, today its best to implement temporallydecoupled R/R messaging explicitly as a sequence of one-way messages. Thisapproach just punts the issue of correlation up to the app level, making you doa lot of work that should rightly be handled by the infrastructure.

SMTP is an interesting platform for thinking about request/response because it requiresa large degree of temporal decoupling to work well. Ideally, you’d liketo be able to initiate a R/R MEP asynchronously, persist all of you app stateto disk, reboot the machine six times, and have the code be able to pick up exactlywhere it left off when it eventually receives the response. SMTP/Mail offers arobust store-and-forward infrastructure for keeping message around until you’reready to retrieve them, but work still needs to happen on the infrastructureside to make sure that there’s a receiving party around capable ofprocessing the response.

Soyou can look at the R/R support in the SMTP transport as something of anexperiment. The network characteristics of mail violate pretty much everyassumption we make about the behavior of request/response messaging, whichmakes it an interesting topic for further study. I generally like things thatviolate assumptions because they do a good job of exposing what you’reassuming…

Tagged as:

#1 Mark Baker on 11.14.2005 at 5:51 AM

Hey, I'm only contrarian when it's required.For stuff that applies principled design techniques to get the desired result, I'm happy to gush.Again, SMTP isn't a transport.If it were, what you're doing would be fine.But it isn't, and that's a key part of why it's been successful, because as an application protocol it provides certain kinds of security guarantees by having a single data-submission semantic, DATA (it's MESTful, AFAICT).All SMTP messages that end up in your inbox, even those with subjects beginning "Re:" are *REQUESTS*; requests correlated via the "In-Reply-To" header.They are not responses in the common distributed systems sense of the word.Turning an SMTP request into a SOAP response is tunneling.That said, tunneling over SMTP isn't uncommon.For example, if you subscribe to a mailing list via email, chances are one of the messages in your inbox will be a *response* to that request.But subscription-via-email is a specific protocol with its own security implications that have been learned the hard way; it is now secure.What isn't secure, is providing a framework for rolling out new, arbitrary applications on top of email, because security implications are per application, not per framework.

#2 Orand on 11.14.2005 at 10:04 AM

TCP isn't a transport.All IP packets that end up at your NIC are *REQUESTS*; requests correlated by TCP headers, not IP headers.They are not responses in the common distributed systems sense of the word.Turning an IP request into a TCP ACK is tunneling.That said, tunneling over IP isn't uncommon.For example, if you send an IP packet containing a TCP SYN to port 23 somewhere, chances are one of the request packets to your NIC will be a *response* to that request.But the TCP handshake is a specific protocol with its own security implications that have been learned the hard way; it is now secure.What isn't secure, is providing a sockets library for rolling out new, arbitrary TCP connections on top of IP, because security implications are per TCP port, not per transport.Rinse, lather, repeat.("HTTP isn't a transport...", "SSL isn't a transport...")

#3 Mark Baker on 11.14.2005 at 11:58 AM

Yes, *gasp*, there's some ambiguity with the terminology.I can only try to use words as they're used in context.The context in which Steve made his claim that a "Re:" message is a "response" is not the same context in which a SOAP message is understood to be a "response".They're two different kinds of responses.As I see it, you can either a) try to struggle along with the rest of us, or b) prepare a glossary and convince the planet to adopt it.

#4 Orand on 11.14.2005 at 6:28 PM

One man's application protocol is another man's transport (or even network!) protocol.Repurposing the level of abstraction is always going to screw up the protocol taxonomists' world view.You can call it tunneling in the short term, but after enough continual use (or misuse) it will become the new standard, shifting the protocol stack down a notch or two.

#5 Mark Baker on 11.14.2005 at 9:24 PM

Interesting theory.While that's certainly what many people are trying to do, it's worth noting that in the six years they've been at it, SOAP traffic on the Internet is practically non-existant.Coincidence?Nope.It was/is *entirely* predictable, simply because there's millions of deployed instances of software doing valuable things that depend on the difference between transport and transfer.For example, firewalls.And if you've spent any time at all with a firewall admin, you know how difficult it is to get them to change their ways.Now multiply that by a million (or 10), and you get some idea as to the momentum behind the status quo.