Socket Send Receive RRS feed

  • Question

  • Hello Fellas,

    Please, help me with the answer.
    I have been dealing with Socket class for years, but usually I used to apply ping-pong method, such as

    1) send guaranteed 4 bytes of Int32 size value of the prepared to send data block
    2) get some OK back
    3) send data
    4) get OK back

    I'm tired of this tech. especially if the ping time is quite long..
    I am still dreaming of how to send a garanteed block of data and be sure it will be received as a quant of data.. not as a group of quants..

    Help me.. do you know any good way..
    Is there any difference between Win32 socket usage and .NET Socket Class? Maybe Async Send/Receive will fix that?

    "I = I + 1" .. Isn't it boolshit?

    Wednesday, October 2, 2019 1:35 AM

All replies

  • No.  What you're talking about is just the way TCP is defined.  It is a "stream" protocol.  Everything that is sent will be delivered, but not in the same block sizes that were sent.

    However, as long as you are sending the block size, there's really no reason for the handshake.  You can send the 4 byte block size, immediately followed by your data block.  The receiving end can read the 4 bytes, and know how many bytes it can pull from the socket.  The receiver will block until all of that data is sent.  TCP is a guaranteed protocol, so it's not like anything will be dropped.  If a packet is lost, the network retries it automatically.

    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Wednesday, October 2, 2019 4:25 AM
  • Thank you, mate.
    Yes, I do that now.. even I have defined the fixed packet size and no need to send 4 bytes before.
    The incoming packs are of the different size, so I'm portioning them before sending..

    Hey, Tim, 

    What do you think, would it be faster if native C/C++ socket32.dll used instead of C# Socket Class?

    "I = I + 1" .. Isn't it boolshit?

    Wednesday, October 2, 2019 7:48 AM
  • In a networked application, the CPU is not the bottleneck.  The bottleneck is in the network.  It doesn't matter what language you're using.

    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Wednesday, October 2, 2019 4:01 PM
  • I Disagree,

    The questuon's not about data transportation time, it is about data Marshaling before they reach Socket32 API and be transported.
    And if the intensity of the transmission is very high and data size is quite heavy - CPU time in CLR is always the bottle neck.

    I am considering the case when high quality audio buffers should be transported in realtime.

    "I = I + 1" .. Isn't it boolshit?

    • Edited by RobbKirk Wednesday, October 2, 2019 10:34 PM
    Wednesday, October 2, 2019 10:29 PM
  • Humm... as long as you allocated and pinned a buffer (actually you'll probably pre-allocate 3 to 5 such blocks in practice) and use it to NetworkStream.Read()/.ReadAsync(), then directly pass the block as is to the target routine, the data transmission itself won't subject to much marshalling costs. (Reference to "actual pointer" translation is fast)

    Thursday, October 3, 2019 8:42 AM
  • Well, I've had the same issue and you've helped me much, Tim. Thank you!
    Thursday, October 3, 2019 9:01 AM
  • Hello cheong00

    I'll try your method.. thanks. ))

    "I = I + 1" .. Isn't it boolshit?

    Thursday, October 3, 2019 1:11 PM