基于 TCP 的基本绑定的 WCF 如何不可靠？

Question

Since i had bad introduction that confused people, I am editing the question and removing the introduction I previously made.

Now, here is the business case for which now I have concerns. C# pseudocode:

 Array.ForEach(files, filename =>
                    {
                        try
                        {
                           WcfServiceClient wcfClient = new WcfServiceClient();
                           wcfClient.SomeMethodWhichPostsFile(filename);
                        }
                        catch (Exception ex)
                        {
                            LogException(ex)
                        }
                    }
                );

I am confused because of existence of WSBinding which is reliable, and basicHTTPBinding is not. I know that WSBinding with reliable sessions guarantees delivery, order, content is encrypted etc. But in the case I described with pseudocode, according to my opinion I have all of these supported even with basicHttpBinding and HTTPS over TCP. TCP provides me reliability, order guarantees and HTTPS encryption.

2. (1. is removed) Am I right related to previous? Or to rephrase: is there an example to show that basicHttpBindind under specified conditions can not provide the same features as WS binding with reliable sessions?

3. My business case requires to accept WCF calls by the order they are issued. If I send them synchronously from the client in a foreach loop (as shown in pseudo code), I assume the order at the server is guaranteed regardless if those are sent within one TCP connection or not, since I am waiting for the response and then I send another request. Even loadbalancer can not disorder messages here since there is no parallelization, messages are sent one by one synchronously. I assume disordering could happen only if I send messages without waiting for response in fire and forget manner and I use different TCP connections. So, am I right here? :)

Answer 1

There are different meanings of the term reliability and the interpretation also depends on the context. Your interpretation of reliability in your question is message is delivered . The interpretation of reliability in the source you cite is instead message is delivered exactly once . Your confusion comes from taking the statement "HTTP is not reliable" which was meant for one interpretation of reliability and using it in the your different interpretation of reliability.

HTTP cannot guarantee that the message gets only delivered once, it can at most guarantee that the message is delivered at least once . It can happen that the underlying TCP connection breaks while sending the request or receiving the response. In this case the client might ignore the problem or retry, which might result in no message delivered (ignoring errors while sending request) but also the same message delivered multiple times (retrying if connections breaks during response). By retrying until the response is received successfully one can guarantee that the message is received at least once, which is your interpretation of reliability but not the one from the statement you cite.