0

I've searched over 2 weeks for samples or anything else for my question. Found some topics and examples but can't use them ...
Here is the problem : I have a server-client application which the server have to listen all the time and client is sending continuously Images to the server.
I've done the send-and-done which means client send 1 image to the server and server receive the image and socket will be closed .
But i want to send continuously Images to the server ...
Found this question : Can a TCP c# client receive and send continuously/consecutively without sleep?
But can't use them and samples .
I know the basic TCP Socket Programming and Basics of Thread Programming , but can't implement this .
Sorry For my bad english !
=====edit
actually a timer captured a screenshot with 1 second interval and these captured images after a process for compressing are send to server .
its continuously sending (Just Sending).
Is there any sample or something that i can use ?
Thanks .

Atrak
  • 11
  • 3
  • 2
    " server receive the image and socket will be closed . " why is the socket closed? do you have control over the server code? Furthermore, we cannot help you really if you don't provide the important code that you have wrote – Mong Zhu Nov 30 '17 at 14:31
  • You have told us what you **cannot** do. You have not told us *why* or *what's the problem*. There is no question we could answer. – nvoigt Nov 30 '17 at 15:10

1 Answers1

2

When sending a single message on a socket, you can just send the payload and close - and the receiver just has to read until the socket reports it has closed and they'll have the message; nice and simple, but it doesn't scale to multiple messages.

You can't just use the packet layout because TCP is implemented as a stream protocol not a packet protocol; how you receive the data does not need to match (in terms of packets) how it is sent.

Thus, to send multiple messages on a TCP socket you need to implement some kind of framing mechanism. Any number of framing mechanism are available. A very simple mechanism might be to send a sequence of:

  • length (4 bytes, little-endian 32-bit integer)
  • payload ({length} bytes)
  • length (4 bytes, little-endian 32-bit integer)
  • payload ({length} bytes)
  • length (4 bytes, little-endian 32-bit integer)
  • payload ({length} bytes)
  • length (4 bytes, little-endian 32-bit integer)
  • payload ({length} bytes)

And similarly the recipient would buffer 4 bytes, interpret the length, then read that many bytes as a frame; rinse, repeat.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900