TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
Posted Aug 2, 2012 12:21 UTC (Thu) by colo (guest, #45564)In reply to: TCP Fast Open: expediting web services by epa
Parent article: TCP Fast Open: expediting web services
I've seen enough GET-requests with at times far-reaching side effects in the wild that I'm not convinced this will (or should) see widespread adoption, at least not for "ordinary" HTTP servers that aren't serving up static content only or something like that.
Posted Aug 2, 2012 13:16 UTC (Thu)
by epa (subscriber, #39769)
[Link] (8 responses)
Posted Aug 2, 2012 14:04 UTC (Thu)
by alankila (guest, #47141)
[Link] (7 responses)
I guess cautious people can't turn TFO on unless they validate the software they runs, but now there is going to be a good reason why you want to ensure that software is idempotent-GET safe. I imagine that the vast majority of software is, actually.
Posted Aug 2, 2012 15:19 UTC (Thu)
by epa (subscriber, #39769)
[Link] (6 responses)
Posted Aug 2, 2012 16:11 UTC (Thu)
by man_ls (guest, #15091)
[Link] (5 responses)
Posted Aug 2, 2012 16:32 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
The client asks if this particular combination of data (provided as GET query parameters) is found in the database overseen by that web service. The server looks in its database (e.g. maybe it's the collection of all voter registration records for a particular country) and if there is a matching record it replies saying what was found and where.
You can run that same request again and get the same exact answer and running it many times or not at all changes nothing‡ so that seems to meet your requirement entirely.
‡ In practice some of the services do accounting, they are incrementing a counter somewhere for every query run and then we use that counter to determine the payment to a third party for the use of their data. But this is no greater deviation from the concept than the usual practice of logging GET requests and anyway most of the services don't do that.
Posted Aug 2, 2012 20:42 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
How can you do a RESTful web service where the client is sending information to the server without causing these sorts of problems?
Posted Aug 3, 2012 2:02 UTC (Fri)
by butlerm (subscriber, #13312)
[Link]
This could presumably be done (up to a point) at the transport layer with TCP Fast Open by having the initiating endpoint assign a unique identifier to a given user space connection request, attaching the identifier as a TCP option, caching the identifier for some reasonable period on the target endpoint, and throwing away SYN packets with connection identifiers that have already been satisfied. The more general way to do that of course is to do it at the application layer, in addition to anything the transport layer may or may not do.
Posted Aug 3, 2012 15:35 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Aug 3, 2012 21:16 UTC (Fri)
by dlang (guest, #313)
[Link]
many groups make everything a GET request, especially for APIs that are not expected to be used from browsers, but rather called from other applications, especially in B2B type situations.
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
That is not required in the RFC, and I am not sure that restful, stateless web services would be even possible. After all, web services are supposed to change state in the server; otherwise what is the point?
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services
TCP Fast Open: expediting web services