none
Keep socket alibe for many messages ? RRS feed

  • Question

  • i want to read messages from a message queue withou establishing every time a complete new connection, because the establishment of the connection takes too much time in case i have a lot of messages. I thought about somethine to keep the Networkstream of the client open, but then i have the problem, that i don't know, how much and how long i can write.

    I though about, to keep the connection alive and just put the messages to the same NetworkStream. But then i'm not shure if there has to be considered about the buffer size ?

    What is best practise ? Habe Anyone some Tips for me ?

    Thanks a lot !

      XmlMessageFormatter msgFormatter = new XmlMessageFormatter(new String[] { "System.String, mscorlib" });
            TcpClient tcpClient = new TcpClient();
            NetworkStream clientSockStream = tcpClient.GetStream();
    
            MessageQueue messageQueue = new MessageQueue(@".\Private$\MsgQueue");
    
            while(true)
            {
                Message peekMessage = messageQueue.Peek();
                SettingsHandler.WriteDebug("Message arrived ! Total: " + messageQueue.GetAllMessages().Length.ToString());
    
                try
                {
                    tcpClient.Connect(SettingsHandler.serverAddress, SettingsHandler.serverPort);
                    // read from queue
                    Message message = messageQueue.Receive();
                    message.Formatter = msgFormatter;
                    // send to server
                    byte[] sendBytes = Encoding.UTF8.GetBytes(message.Body.ToString());
                    clientSockStream.Write(sendBytes, 0, sendBytes.Length);
                    clientSockStream.Close();
                    tcpClient.Close();
                }
                catch (Exception e)
                {
                    SettingsHandler.WriteDebug("SocketException: {0}" + e.Message);
                    SettingsHandler.WriteDebug("Server not available, retry in 5 seconds. !");
                    Thread.Sleep(5000);
    
                }
            }

    Friday, June 22, 2018 5:58 AM

All replies

  • I have to admit, that I don't understand your approach at all..

    What is the use-case for polling messages from the queue and then resending them manually? Why isn't server listening to the queue?

    I would consider using SignalR or at least using a separate thread to poll the queue, accumulate messages over a certain time window and send them bundled to the server.

    Friday, June 22, 2018 8:33 AM
  • The server which the data will be sent to could be any kind of external system. So the first idea was just to use a socket connection. 

    But thats not a bad idea to let the external systems use message queues. But for that windows must running on the other system right ? 

    Friday, June 22, 2018 9:23 AM
  • You're talking about creating a wrapper for a message queue. Thus you will loose queue functionality here. So the question is: what are the design goals?

    Do you want to keep the message structure?

    Then using a stream is imho not the correct approach, cause this means that you need to implement your own messaging protocol for it. Here I would consider using single UDP messages.

    When not, I would use a process or thread to collect the messages from the queue and persist them. A second process thread would then bundle them and send them in intervals.

    Friday, June 22, 2018 10:35 AM
  • And for the queues at the other server:

    Take a look at https://www.rabbitmq.com/.

    Friday, June 22, 2018 10:36 AM
  • This can be done, but it requires that both the client AND the server know about it.  You will need to have some signal that tells you when a message is done.  In HTTP, for example, there's a Content-Length header that tells the receiver exactly how many bytes are coming.  In SMTP, a line that contains nothing but a dot is the signal that "this exchange is over".

    As long as you know exactly when one transaction is finished, you can circle back to wait for more data, instead of opening another socket.

    But, as I said, the server will ALSO need to know not to close the socket.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Friday, June 22, 2018 7:45 PM