There is a need for a program that allows musicians to jam on the network, and there is a desire to write it. This requires that the delivery of audio (byte arrays, about 1 kb in size) is carried out with a minimum delay (no more than 10 ms). Is it possible to achieve this? If so, how? (Transmission protocol, compression, network type (p2p or server-client), etc.) I would like to write in C # or C ++.

UPD : still interested in this moment. To reduce latency, I think packing data in GZip. Please tell me if it makes sense? I mean, would it not be faster to simply send unpacked data than to pack, send, and then unpack first?

  • UDP is almost certain. And rather not .NET, but pluses. - Vladimir Martyanov
  • @ Vladimir Martianov, thank you for the advice. - Ragnar
  • 3
    Will you have such a ping? This is for starters. - VladD
  • one
    p2p is more likely to give less delay. Although there may of course be a situation that routing to the server from both clients is 2 times less than the direct route of p2p, but I think this is still rare. Then we decide what is more important for us if there is a delay in transmitting a portion of data, ignore (discard) and catch the next one, or wait, but without loss. If the first is UDP, the second is TCP. - Mike
  • one
    And at the expense of compression ... Ideally, you need one package to fit in the MTU. The UDP / IP header counts 40 bytes. The MTU Ethernet has 1500 bytes, it can be already in places on the Internet. If the MTU fit - then compression, unnecessary actions. - Mike

2 answers 2

First, I will answer questions, then, with permission, I will express my opinion on the idea.

You can achieve delays of 10 ms, for example, when connecting point-to-point or in a simple local area network. But in your case it is almost unreal. For example, right now I have a ping to the gateway 75-80 ms. In addition to the fact that the packets will be lost, they will also be delivered with non-permanent time, that is, there will be a jiter.

The transport protocol is uniquely UDP. Although there is still CSTP , but it has limited support from providers, it is likely that there will be a node that will cut everything that is not UDP and not TCP. And in Vindouz he is generally a poor relative. On the application level, I recommend to get acquainted with the RTP .

P2P as in bittorent will not help you if the city network is strictly centralized, which is often the case in smaller cities. That is, if the provider has one gateway for all and to it centrally all channels from average users converge. It turns out that there will be one channel between participants and the bittorent will most likely lose because he has his own overhead too. The bit torrent needs redundant channels, then there is the possibility of parallel transmission, which is its essence.

You can try to organize P2P in Skype . For example, if among the three participants it turns out that 2 is more profitable to be an intermediary between 1 and 3, then you can designate 2 as a server for 1 and 3. Then he will have to transfer for 1: himself and 3, and for 2: himself and 1. For more participants will need to select intermediaries for each channel. That is, this is the maximum flow task.

It is definitely necessary to try to compress, but not with a zip, but with an audio codec. It is likely that compression / decompression can be done in hardware.

Now the opinion about the venture. Why did you even decide that a delay of 10 ms will be enough, music is a subtle thing. The big orchestra is usually managed by a conductor because the musicians simply do not hear each other. I recommend you look at the radio.

  • You have something strange about P2P written. Even with the “hard centralization” of the network, P2P still benefits the server solution - because the server is not necessarily at the center of the network! - Pavel Mayorov
  • @PavelMayorov What does not mean necessarily? All traffic between nodes through the central server is chasing, they have no alternative channels between themselves. - Cerbo
  • Why do you think that traffic is “chasing through the central server”? The center of the provider network is a router, not a server. The server will be at best - in the server row (short beam from the router), at worst - at the author's home (on the same long beam as all clients). - Pavel Mayorov
  • From the perspective of the provider, the hypothetical Ragnar server is no different from any other computer. - Pavel Mayorov
  • @PavelMayorov Apparently I didn’t accurately formulate, by P2P I mean something ala bittorent or Skype for example. - Cerbo

I certainly can not fully figured out the question! But in order to send data that does not fit into a single UDP packet (TCP) with minimal delays and minimal load on the network, you can use the packet pool send technology (SendQueue) implemented in WinPcap (LibPcap). Here everything is popularly explained with examples in C # https://pcapdotnet.codeplex.com (section https://pcapdotnet.codeplex.com/SourceControl/latest#PcapDotNet.DevelopersPack/src/SendingPacketsUsingSendBuffer/Program.cs ).