bslorence
asked on
Can I force my SOAP client to re-use an existing connection on subsequent calls to a service?
Hi,
I'm writing a SOAP client in C#. It uses a WSDL-generated class that's derived from SoapHttpClientProtocol -- pretty standard stuff. The service that I'm querying uses SSL, and I'd like to avoid the overhead of the SSL handshake in those situations where I have to make several calls to the service back-to-back. I've been looking at the .NET documentation on MSDN, but haven't found any way to prevent my client from opening a new TCP connection to the service every time I invoke the main SOAP method.
I know that the client is opening a new connection each time, because I've watched the TCP traffic in Ethereal as the client runs. In my particular situation, I'm calling the same SOAP method repeatedly from within a tight foreach() loop, so there's no reason why the client couldn't re-use the original connection -- I just don't know how to specify that it should. Is this possible?
I've labelled this question "easy" because I'm guessing that there's a simple boolean property that I need to set somewhere, that I just don't know about. If the implementation is more in-depth, I will upgrade the point-value accordingly.
Thanks,
Ben
I'm writing a SOAP client in C#. It uses a WSDL-generated class that's derived from SoapHttpClientProtocol -- pretty standard stuff. The service that I'm querying uses SSL, and I'd like to avoid the overhead of the SSL handshake in those situations where I have to make several calls to the service back-to-back. I've been looking at the .NET documentation on MSDN, but haven't found any way to prevent my client from opening a new TCP connection to the service every time I invoke the main SOAP method.
I know that the client is opening a new connection each time, because I've watched the TCP traffic in Ethereal as the client runs. In my particular situation, I'm calling the same SOAP method repeatedly from within a tight foreach() loop, so there's no reason why the client couldn't re-use the original connection -- I just don't know how to specify that it should. Is this possible?
I've labelled this question "easy" because I'm guessing that there's a simple boolean property that I need to set somewhere, that I just don't know about. If the implementation is more in-depth, I will upgrade the point-value accordingly.
Thanks,
Ben
ASKER
1) 1.1.4322.573
2) I'm not sure what you mean. It's a single-request, single-response call. One complex object is sent over the wire, and one is returned.
3) Absolutely. In fact, that's how I originally designed my client. The service was designed by a vendor of one of my customer's. In the vendor's design documents, the complex object that is sent is referred to as a "batch", and one of its members is an array of "order" objects. So naturally, I designed the client so that when there were several orders to send, it would load them into the array and send them together in one batch. Then when I started running into a lot of service-side problems, the vendor's developers admitted that they had never anticipated that there would be any more than one order sent per batch, and suggested that I send one order per batch "to be on the safe side", or something to that effect.
I protested that this would be inefficient and cited some numbers from my test results, to the effect that it would take *at least* twice as long to send a moderately-szied group of orders if I sent one order per batch. The vendor countered that the bottleneck in sending one order per batch was in the SSL handshake.
Frankly, I think that this is nonsense -- as I mentioned above, I've watched the TCP traffic in Ethereal and I can see that the SSL handshake is not the bottleneck. But knowing the vendor, it's going to take more than my word to prove it. So I was hoping for a way to force .NET to re-use the existing connection, so as not to leave the vendor any wiggle room, and basically force them to admit that sending one order-per-batch is horribly inefficient, and that the inefficiency is not SSL's fault.
4) I see what you mean, but what about scaling down? ;-) Shouldn't I at least have the option available?
I'm going to upgrade the point-value, because it sounds like this isn't as easy as I had first hoped (if it's possible at all).
2) I'm not sure what you mean. It's a single-request, single-response call. One complex object is sent over the wire, and one is returned.
3) Absolutely. In fact, that's how I originally designed my client. The service was designed by a vendor of one of my customer's. In the vendor's design documents, the complex object that is sent is referred to as a "batch", and one of its members is an array of "order" objects. So naturally, I designed the client so that when there were several orders to send, it would load them into the array and send them together in one batch. Then when I started running into a lot of service-side problems, the vendor's developers admitted that they had never anticipated that there would be any more than one order sent per batch, and suggested that I send one order per batch "to be on the safe side", or something to that effect.
I protested that this would be inefficient and cited some numbers from my test results, to the effect that it would take *at least* twice as long to send a moderately-szied group of orders if I sent one order per batch. The vendor countered that the bottleneck in sending one order per batch was in the SSL handshake.
Frankly, I think that this is nonsense -- as I mentioned above, I've watched the TCP traffic in Ethereal and I can see that the SSL handshake is not the bottleneck. But knowing the vendor, it's going to take more than my word to prove it. So I was hoping for a way to force .NET to re-use the existing connection, so as not to leave the vendor any wiggle room, and basically force them to admit that sending one order-per-batch is horribly inefficient, and that the inefficiency is not SSL's fault.
4) I see what you mean, but what about scaling down? ;-) Shouldn't I at least have the option available?
I'm going to upgrade the point-value, because it sounds like this isn't as easy as I had first hoped (if it's possible at all).
1) Do you know anything about Fiddler? You can use it to examine your http: and https: traffic.
2) Here is an article on "chatty"
Chatty or Chunky Interfaces
http://www.topxml.com/WS-web-services/re-23252_Chatty-or-Chunky-Interfaces.aspx
"Chatty" just means a lot of back-and-forth requests or a bunch of single requests, where one big request would be better.
3) Most things for the web are built for scaleability, so scaling down usually is not an option.
Bob
2) Here is an article on "chatty"
Chatty or Chunky Interfaces
http://www.topxml.com/WS-web-services/re-23252_Chatty-or-Chunky-Interfaces.aspx
"Chatty" just means a lot of back-and-forth requests or a bunch of single requests, where one big request would be better.
3) Most things for the web are built for scaleability, so scaling down usually is not an option.
Bob
ASKER
1) Fiddler looks very cool, thank you. I'll keep it in mind in the future. But since I don't need to be setting breakpoints or modifying headers on-the-fly, Ethereal has been a good enough tool for me to tell that the bottleneck is not SSL -- and that's all I needed it for.
2) Thanks for the link. Maybe I'm missing something obvious, but I couldn't find any article when I followed that link. Just a single paragraph mentioning that the poster thought it would be a good idea to share the article.
3) On the question of scaleability, I agreed right away in my first response, but then it got me thinking. In what sense is it more scaleable to use a new TCP connection for every request to the same server? It seems to me that this sort of implementation could actually waste system resources. I would imagine that there is a limit in Windows to the number of connections that can be open at once; what if I had a whole bunch of clients running on one machine at the same time? Theoretically I could run out of connections a lot faster if each client insisted on opening a new connection for every request. Or am I missing something?
Thanks,
Ben
2) Thanks for the link. Maybe I'm missing something obvious, but I couldn't find any article when I followed that link. Just a single paragraph mentioning that the poster thought it would be a good idea to share the article.
3) On the question of scaleability, I agreed right away in my first response, but then it got me thinking. In what sense is it more scaleable to use a new TCP connection for every request to the same server? It seems to me that this sort of implementation could actually waste system resources. I would imagine that there is a limit in Windows to the number of connections that can be open at once; what if I had a whole bunch of clients running on one machine at the same time? Theoretically I could run out of connections a lot faster if each client insisted on opening a new connection for every request. Or am I missing something?
Thanks,
Ben
Sorry, I lost track of this one:
3) If you keep the same connection over time, and there is only a limited pool of resources, you run out, and that is against the guidelines of scaleability.
Bob
3) If you keep the same connection over time, and there is only a limited pool of resources, you run out, and that is against the guidelines of scaleability.
Bob
ASKER
Setting aside the question of scaleability, where do we go from here with this EE question?
1) Resolution to this question is up to you
2) I don't believe that you can accomplish what you are looking for in the context of how the .NET framework works (I may be wrong)
3) When questions don't get answered, the recommended course of action is to ask for Delete/Refund in Community Support
Bob
2) I don't believe that you can accomplish what you are looking for in the context of how the .NET framework works (I may be wrong)
3) When questions don't get answered, the recommended course of action is to ask for Delete/Refund in Community Support
Bob
ASKER
OK, I requested that the question be deleted:
https://www.experts-exchange.com/questions/21926386/25-Jul-please-close-21875275.html
Ben
https://www.experts-exchange.com/questions/21926386/25-Jul-please-close-21875275.html
Ben
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
2) How "chatty" is the call?
3) Would it be possible to convert this to a single call, instead of multiple calls?
4) AFAIK it is not possible to force the same connection to be used. With this you have scaleability, since you are not keeping connections open, and then run out of resources.
Bob