Is it possible to guarantee ordered delivery with oneWay calls using namedPipe binding?

I have a WCF service/client communicating using namedPipe binding. The client is exposing a callback contract in which all the methods in the callback are marked as OneWay. Something like this

[ServiceContract(CallbackContract = typeof(IMyServiceCallback))]  
public interface IMyService  
{  
    [OperationContract]  
    void MyOperation();  
}

public interface IMyServiceCallback  
{  
   [OperationContract(IsOneWay=true)]
   void MyCallback1();

   [OperationContract(IsOneWay=true)]
   void MyCallback2();  
}  

At the server side, the implementation of MyOperation method always calls MyCallback1 first and then MyCallback2 but I am observing that sometimes the client receives the calls in the incorrect order (MyCallback2 first and then MyCallb开发者_开发问答ack1).

On searching the internet I found that the order is not guaranteed with oneway operation as mentioned here and also there is something called reliableSession which ensure message ordering.

All the examples on the internet for reliable session are with TCP binding (and not a single one with NamedPipeBinding) and the tcpBinding also has a property called ReliableSession which is not present on the NetNamedPipeBinding. So I am not sure whether reliable session is expected to work with NetNamedPipeBinding or not.

Question:

Does reliable session work with namedPipeBinding? If yes, how? If no, Is there any other approach with which I can guarantee ordered delivery?

http://msdn.microsoft.com/en-us/library/aa480191.aspx

Introduction to Reliable Messaging with the Windows Communication Foundation

...

The NetNamedPipeBinding sits on top of the Windows operating system's support for reliable message delivery and reliable streams through named pipes. Because named pipes are connection-oriented, readily support sessions, are reliable by design, and are typically not bridged, there is no need for WS-RM support in this binding.

Chances are, your messages are being delivered in the order the server sends them, and the latter is what you need to work with. The server may be running concurrently and offer no guarantee for ordered dispatch.

Then again, I could be wrong. From my link above, there are some attributes you can specify on your contract and implementation that control ordered delivery.

This question has some more information as well.