We have to deal with this at work. It’s the pain of moving large data across the network via HTTP. You have no idea how large the data is going to be or how long the SQL query will take to execute u til after the HTTP request is issued by which time the request TTL is already defined.
This is a self inflicted pain though. You shouldn’t be using HTTP to move large data. A streaming socket is so much more efficient.
The transport protocol doesn't matter. You will have the same problem no matter the transport layer. Yes socket is probably going to be faster, but not paginating correctly will cost you more memory, CPU and money.
That is so far outside of reality. How do you think your VOIP calls work? They don't paginate data. They just pipe from one buffer to another where the second buffer is a network socket. The network socket doesn't care what the data looks like or how big it is. It will just push forward what its fed until either end of message or socket termination.
We have to deal with this at work. It’s the pain of moving large data across the network via HTTP. You have no idea how large the data is going to be or how long the SQL query will take to execute u til after the HTTP request is issued by which time the request TTL is already defined.
This is a self inflicted pain though. You shouldn’t be using HTTP to move large data. A streaming socket is so much more efficient.
The transport protocol doesn't matter. You will have the same problem no matter the transport layer. Yes socket is probably going to be faster, but not paginating correctly will cost you more memory, CPU and money.
That is so far outside of reality. How do you think your VOIP calls work? They don't paginate data. They just pipe from one buffer to another where the second buffer is a network socket. The network socket doesn't care what the data looks like or how big it is. It will just push forward what its fed until either end of message or socket termination.