Sent Confirmation

[Anonymous]

Hello there. This is my first posting on here so please forgive me if my terminology is incorrect or something like that.

I’m trying to get a confirmation sent back to the client when they send a message to the server. Something simple like “true” or “Got It” just so that the client knows for a fact that the server has in fact retrieved it.

When looking through I did find some information on a feature like this, however I did not understand the term “expectedReturnPacketTypeStr”. I tried a couple of different strings but had no luck. My knowledge in networking is limited and that’s why I’m loving this dll! So great!

Here is an example of what my client would send to the server.
string test = NetworkComms.SendReceiveObject<string>("Message", serverIP, serverPort, expectedReturnPacketTypeStr, 2000, messageToSend);

Any advice would be much appreciated, thank you!

[Anonymous]

I managed to figure it out.

I had to have the expectedReturnPacketTypeStr be the name/header of the message and then on the server side have a
connection.SendObject("Confirm", "Got It");

This way once the message was sent then it would look for the “Confirm”. Makes more sense now.

[Anonymous]

What you have found is one possible way of having confirmation packets. Having said that this functionality is actually provided within the core feature set. You can enable this functionality on a global basis, per connection or per send basis by creating a new SendRecieveOptions list. The following forces a receive confirmation:

SendReceiveOptions newOptions = (SendReceiveOptions)NetworkComms.DefaultSendReceiveOptions.Clone();
newOptions.ReceiveConfirmationRequired = true;

Connection conn = TCPConnection.GetConnection(connectionInfo, newOptions);

try
{
    conn.SendObject("Message", "this is a test message");
}
catch (ConfirmationTimeoutException)
{
    //If the server does not send a recieve confirmation within the default timeout this exception will be thrown.
}

This is handled automatically by the receiving end so that you do not have to worry about it.

Regards,
Marc

[Anonymous]

I can’t get this to work.

I get ‘Confirmation Packet timeout’.
But on the client side the message is received and displayed.

Am I supposed to do something in the handler on the client ?

Im using Xamarin on android.

• This reply was modified 10 years, 8 months ago by .

[Anonymous]

Heya Billy,

Many kind thanks for the post. Sorry to hear you are having problems.

Nothing needs to be configured on the client side. A few questions:

1. Is this problem 100% reproducible?
2. Have you tried enabling logging to see what might be happening to the confirmation packets?

Regards,
Marc

[Anonymous]

it is 100% reproducible. here is my log, with logging on.
I get ‘Confirmation packet timeout.’

thanks.

15.32.10.965 [1 – Trace] – RetrieveConnection by remoteEndPoint=’192.168.0.9:11004′, localEndPoint=’0.0.0.0:0′, connectionType=’TCP’ and ApplicationLayerProtocolStatus=’Enabled’. 1 matching connections found.
15.32.10.966 [1 – Trace] – Attempted to create new TCPConnection to connectionInfo='[TCP-E] 0.0.0.0:0 -> 192.168.0.9:11004′ but there is an existing connection. Existing connection will be returned instead.
15.32.10.978 [1 – Trace] – … created nested packet of type ChatMessage
15.32.11.429 [1 – Trace] – … created packet of type ChatMessage. PacketObject data size is 112 bytes
15.32.11.429 [1 – Trace] – Entering packet send of ‘NestedPacket’ packetType to [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A)
15.32.11.439 [1 – Info] – Added connection specific incoming packetHandler for ‘Confirmation’ packetType with [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A)
15.32.11.442 [1 – Debug] – Added a connection specific shutdown delegate to connection with [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A)
15.32.11.443 [1 – Debug] – Sending a packet of type ‘NestedPacket’ to [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A) containing 73 header bytes and 112 payload bytes. Allowing 1000.0 ms/KB for send.
15.32.11.445 [1 – Trace] – … 0.181KB sent at average of 115.440KB/s. Current:0.00 ms/KB, Connection Avg:11.21 ms/KB.
15.32.11.445 [1 – Trace] – … waiting for receive confirmation packet.
15.32.16.489 [1 – Info] – Removed a connection specific packetHandler for ‘Confirmation’ packetType. No handlers remain with [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A)
15.32.16.517 [1 – Debug] – Removed ConnectionSpecificShutdownDelegate to connection with [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A)
15.32.16.520 [1 – Info] – No handlers remain for ConnectionSpecificShutdownDelegate with [TCP-E] 192.168.0.2:36606 -> 192.168.0.9:11004 (anZ59HI-EEqV4Jtbwd944A)

[Anonymous]

The matching part of the server side log would also be useful.

Have you tried increasing the default confirmation time-out to something like 60 seconds to rule out some network latency issue? See NetworkComms.PacketConfirmationTimeoutMS.

Regards,
Marc

[Anonymous]

Tried the timout, no help.

I have 3 logs for you. (this isn’t the only thing that doesn’t work. Broadcasts don’t work either. I have had to implement my own broadcast using the stand c# UpdClient – I might cover that once this works.).

Client sending to the server Log (time out is 1000).
=========================
12.20.11.517 [1 – Trace] – … created packet of type ChatMessage. PacketObject data size is 112 bytes
12.20.11.517 [1 – Trace] – Entering packet send of ‘NestedPacket’ packetType to [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA)
12.20.11.524 [1 – Info] – Added connection specific incoming packetHandler for ‘Confirmation’ packetType with [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA)
12.20.11.527 [1 – Debug] – Added a connection specific shutdown delegate to connection with [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA)
12.20.11.528 [1 – Debug] – Sending a packet of type ‘NestedPacket’ to [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA) containing 73 header bytes and 112 payload bytes. Allowing 1000.0 ms/KB for send.
12.20.11.531 [1 – Trace] – … 0.181KB sent at average of 88.691KB/s. Current:7.01 ms/KB, Connection Avg:5.95 ms/KB.
12.20.11.532 [1 – Trace] – … waiting for receive confirmation packet.
Thread finished: <Thread Pool> #9
Thread finished: <Thread Pool> #9
12.20.16.580 [1 – Info] – Removed a connection specific packetHandler for ‘Confirmation’ packetType. No handlers remain with [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA)
12.20.16.607 [1 – Debug] – Removed ConnectionSpecificShutdownDelegate to connection with [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA)
12.20.16.612 [1 – Info] – No handlers remain for ConnectionSpecificShutdownDelegate with [TCP-E] 192.168.0.9:45870 -> 192.168.0.15:11004 (pxxQQRnnVkiXAZfkiHfqrA)
[Choreographer] Skipped 391 frames! The application may be doing too much work on its main thread.
12.20.28.89 [15 – Trace] – Starting AllConnectionsSendNullPacketKeepAlive
12.20.28.96 [15 – Trace] – RetrieveConnection by remoteEndPoint=’0.0.0.0:0′, localEndPoint=’0.0.0.0:0′, connectionType=’Undefined’ and ApplicationLayerProtocolStatus=’Enabled’. 3 matching connections found.
12.20.28.101 [16 – Trace] – Sending null packet to [TCP-E] 192.168.0.9:11004 -> 192.168.0.15:47114 (pxxQQRnnVkiXAZfkiHfqrA)
Thread started: ManagedThreadPool_18 #16

Server Log
========
12.17.6.426 [12 – Trace] – … checking for completed packet with 185 bytes read.
12.17.6.428 [12 – Debug] – Received packet of type ‘NestedPacket’ from [TCP-E] 192.168.0.15:11004 -> 192.168.0.9:58992 (8NNKKsnL2EivcBCg4tVHvw), containing 73 header bytes and 112 payload bytes.
12.17.6.430 [12 – Trace] – … handling packet type ‘NestedPacket’ inline. Loop index – 0. pSeq#-8.
12.17.6.432 [12 – Trace] – Unwrapping a NestedPacket packet from [TCP-E] 192.168.0.15:11004 -> 192.168.0.9:58992 (8NNKKsnL2EivcBCg4tVHvw) with a priority of Lowest.
12.17.6.709 [12 – Trace] – Handling a ChatMessage packet from [TCP-E] 192.168.0.15:11004 -> 192.168.0.9:58992 (8NNKKsnL2EivcBCg4tVHvw) with a priority of Normal.
12.17.6.709 [12 – Trace] – Triggering handlers for packet of type ‘ChatMessage’ from [TCP-E] 192.168.0.15:11004 -> 192.168.0.9:58992 (8NNKKsnL2EivcBCg4tVHvw)
12.17.6.714 [12 – Trace] – … passing completed data packet of type ‘ChatMessage’ to 1 selected global handlers.
12.17.6.749 [12 – Trace] – … all handlers for packet of type ‘ChatMessage’ completed.
12.17.6.749 [12 – Trace] – Removing 185 bytes from incoming packet builder from connection with [TCP-E] 192.168.0.15:11004 -> 192.168.0.9:58992 (8NNKKsnL2EivcBCg4tVHvw).

Client sending to server, waiting 60 seconds for a reply
===========================================
12.24.26.454 [1 – Trace] – RetrieveConnection by remoteEndPoint=’192.168.0.15:11004′, localEndPoint=’0.0.0.0:0′, connectionType=’TCP’ and ApplicationLayerProtocolStatus=’Enabled’. 1 matching connections found.
12.24.26.455 [1 – Trace] – Attempted to create new TCPConnection to connectionInfo='[TCP-E] 0.0.0.0:0 -> 192.168.0.15:11004′ but there is an existing connection. Existing connection will be returned instead.
12.24.26.476 [1 – Trace] – … created nested packet of type ChatMessage
[Mono] GC_BRIDGE num-objects 3796 num_hash_entries 3890 sccs size 3880 init 0.00ms df1 6.71ms sort 5.14ms dfs2 1.46ms setup-cb 1.80ms free-data 1.33ms user-cb 60.05ms clenanup 5.79ms links 143/143/201/2 dfs passes 29220/14726
[Mono] GC_MINOR: (Nursery full) pause 39.77ms, total 40.20ms, bridge 75.68ms promoted 240K major 1888K los 3736K
12.24.26.962 [1 – Trace] – … created packet of type ChatMessage. PacketObject data size is 112 bytes
12.24.26.963 [1 – Trace] – Entering packet send of ‘NestedPacket’ packetType to [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q)
12.24.26.968 [1 – Info] – Added connection specific incoming packetHandler for ‘Confirmation’ packetType with [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q)
12.24.26.970 [1 – Debug] – Added a connection specific shutdown delegate to connection with [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q)
12.24.26.971 [1 – Debug] – Sending a packet of type ‘NestedPacket’ to [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q) containing 73 header bytes and 112 payload bytes. Allowing 1000.0 ms/KB for send.
12.24.26.974 [1 – Trace] – … 0.181KB sent at average of 108.377KB/s. Current:0.00 ms/KB, Connection Avg:11.49 ms/KB.
12.24.26.975 [1 – Trace] – … waiting for receive confirmation packet.
Thread finished: <Thread Pool> #10
Thread finished: <Thread Pool> #10
12.24.44.445 [11 – Trace] – … null packet removed in IncomingPacketHandler() from [TCP-E] 192.168.0.9:11004 -> 192.168.0.15:38785 (uvx241iosEWKD5GOQdXD-Q). 1
12.24.44.551 [14 – Trace] – Starting AllConnectionsSendNullPacketKeepAlive
12.24.44.558 [14 – Trace] – RetrieveConnection by remoteEndPoint=’0.0.0.0:0′, localEndPoint=’0.0.0.0:0′, connectionType=’Undefined’ and ApplicationLayerProtocolStatus=’Enabled’. 3 matching connections found.
12.25.14.550 [11 – Trace] – … null packet removed in IncomingPacketHandler() from [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q). 1
12.25.14.578 [14 – Trace] – Starting AllConnectionsSendNullPacketKeepAlive
12.25.14.582 [14 – Trace] – RetrieveConnection by remoteEndPoint=’0.0.0.0:0′, localEndPoint=’0.0.0.0:0′, connectionType=’Undefined’ and ApplicationLayerProtocolStatus=’Enabled’. 3 matching connections found.
12.25.14.600 [17 – Trace] – Sending null packet to [TCP-E] 192.168.0.9:11004 -> 192.168.0.15:38785 (uvx241iosEWKD5GOQdXD-Q)
Thread started: <Thread Pool> #16
12.25.27.14 [1 – Info] – Removed a connection specific packetHandler for ‘Confirmation’ packetType. No handlers remain with [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q)
12.25.27.49 [1 – Debug] – Removed ConnectionSpecificShutdownDelegate to connection with [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004 (uvx241iosEWKD5GOQdXD-Q)
12.25.27.54 [1 – Info] – No handlers remain for ConnectionSpecificShutdownDelegate with [TCP-E] 192.168.0.9:37844 -> 192.168.0.15:11004

[Anonymous]

Billy, I’ve emailed you a possible hotfix that contains a more up to date revision of 3.0.0. It has not been put together to specially address this issue but it does contain several bug fixes. Please let us know if this problem still exists with that.

Regards,
Marc

[Anonymous]

I tried the new dlls’s, makes no difference, still broken.

[Author]

Posts