Home Forums Support new TCPConnection WITHOUT being reused

Viewing 6 posts - 11 through 16 (of 16 total)
  • Author
    Posts
  • #4039
    Anonymous
    Inactive

    Hello Marc,

    I see what you are suggesting, and I am doing so, however, the problem is NOT with the server, the problem is with the clients.

    If you see the code I posted in the original topic, I’m using the packet type “RequestReply”.
    The problem is that if I have the multiple clients sending the same packet type at the same time, the replies which are handled by the server and using the same example as in the Sync send/receive (https://networkcomms.net/synchronous-send-and-receive/)

    My code (in the server) is something like this:

    
    private void ProcessRequestReply<T>(PacketHeader packetHeader, Connection connection, T inputObject)
    {
          BasicRequest input = null;
          input = inputObject as BasicRequest;
    
          string errorText = String.Format("!!!dummy error|{0}|{1}", -100, "Error Message with reason");
          connection.SendObject("Reply", new BasicReply(input.MessageId, errorText));
    }
    

    The reply is sent to the connection that is shared by all clients, so there is no way to be sure who will receive it.

    Am I making sense now?

    Regards
    Joao

    • This reply was modified 8 years, 9 months ago by .
    #4049
    Anonymous
    Inactive

    On the server, instead of using “Reply” as the return packet type, why not use “Reply.1” and “Reply.2”? Then configure the client to use these types as the expected return.

    What you want to achieve it very easy to do in NetworkComms.Net, you are just missing the tremendous flexibility offered by named packet types.

    On the server:

    
    //Handle incoming packet type "Message.1"
    private void ProcessRequestReply<T>(PacketHeader packetHeader, Connection connection, T inputObject)
    {
          BasicRequest input = null;
          input = inputObject as BasicRequest;
     
          string errorText = String.Format("!!!dummy error|{0}|{1}", -100, "Error Message with reason");
          connection.SendObject("Reply.1", new BasicReply(input.MessageId, errorText));
    }
    
    //Handle incoming packet type "Message.2"
    private void ProcessRequestReply<T>(PacketHeader packetHeader, Connection connection, T inputObject)
    {
          BasicRequest input = null;
          input = inputObject as BasicRequest;
     
          string errorText = String.Format("!!!dummy error|{0}|{1}", -100, "Error Message with reason");
          connection.SendObject("Reply.2", new BasicReply(input.MessageId, errorText));
    }
    

    On the client:

    
    //Send "Message.1" and expect "Reply.1" back.
    connection.SendReceiveObject<String>("Message.1", "Reply.1", 1000);
    
    //Send "Message.2" and expect "Reply.2" back.
    connection.SendReceiveObject<String>("Message.2", "Reply.2", 1000);
    

    This methodology is demonstrated in the AdvancedSend.cs example.

    #4051
    Anonymous
    Inactive

    Hello Marc,

    I wasn’t aware I could use the reply packet type with whatever string I wanted.

    Since I have a unique message id per request (GUID), I’ve tested something like

    
    var result = m_Connection.SendReceiveObject<BasicRequest, BasicReply>("RequestReply", string.Format("Reply.{0}", request.MessageId), timeout, request);
    

    and used a similar reply in the server and everithing worked just fine!

    Thanks and sorry for such a long thread!

    Joao

    • This reply was modified 8 years, 9 months ago by .
    #4068
    Anonymous
    Inactive

    I have the same problem here and this thread solved my issue …

    Basically different thread in the same application send the same packet-type to a server with a blocking SendReceiveObject call … but the responses were messed up … one thread get the response pertinent to another one …

    I found very strange that this is not working out of the box … very confusing for me.

    Anyway marking the response with a unique SendingPacketType for every packet solved the issue … thanks again for this thread!!

    #4069
    Anonymous
    Inactive

    I’m glad I wasn’t the only one that found the behaviour confusing and misleading.

    Anyway, I’m glad this helped you as well!

    #4074
    Anonymous
    Inactive

    Thanks for all of the information guys. It does make sense that this behaviour may be unexpected. From memory I believe this was done as one of many performance optimisations. These days however, I’m undecided what the best behaviour is. I’ll keep this thread bookmarked for future consideration.

    Kind regards,
    Marc

Viewing 6 posts - 11 through 16 (of 16 total)
  • You must be logged in to reply to this topic.