new TCPConnection WITHOUT being reused

[Anonymous]

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 9 years, 4 months ago by .

[Anonymous]

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.

[Anonymous]

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 9 years, 4 months ago by .

[Anonymous]

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!!

[Anonymous]

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!

[Anonymous]

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

[Author]

Posts