0

I have a one-on-one connection between a server and a client. The server is streaming real-time audio/video data.

My question may sound weird, but should I use multiple ports/socket or only one? Is it faster to use multiple ports or a single one offer better performance? Should I have a port only for messages, one for video and one for audio or is it more simple to package the whole thing in a single port?

One of my current problem is that I need to first send the size of the current frame as the size - in bytes - may change from one frame to the next. I'm fairly new to Networking, but I haven't found any mechanism that would automatically detect the correct range for a specific object being transmitted. For example, if I send a 2934 bytes long packet, do I really need to tell the receiver the size of that packet?

I first tried to package the frame as fast as they were coming in, but I found out the receiving end would sometime not get the appropriated number of bytes. Most of the time, it would read faster than I send them, getting only a partial frame. What's the best way to get only the appropriated number of bytes as quickly as possible?

Or am I looking too low and there's a higher-level class/framework used to handle object transmission?

LightStriker
  • 19,738
  • 3
  • 23
  • 27
  • The biggest thing you should do is totally forget about *packets*. A TCP connection is a **stream**, so any delineation of data needs to be handled by *you* (the protocol). – Jonathon Reinhart Jul 11 '13 at 06:00
  • Also, UDP *datagrams* are usually used for streaming. – Jonathon Reinhart Jul 11 '13 at 06:01
  • @JonathonReinhart: It's maybe a stream, but I need to chop it off in packets - or frames - otherwise the client will only process junk - half frames or overlapping frames. I simply don't know what's the best or most efficient way of doing this. Obviously I need to do a lot more than just shoving the data in the pipe and hope for the best. – LightStriker Jul 11 '13 at 06:06
  • That's what I'm saying, you need to come up with a protocol that says "hey, here's the data that's coming behind me". I'm saying you should forget about the actual TCP/IP packets flowing underneath your stream. – Jonathon Reinhart Jul 11 '13 at 06:08
  • But really, you should consider [using UDP for streaming protocols](http://stackoverflow.com/questions/6187456/tcp-vs-udp-on-video-stream). – Jonathon Reinhart Jul 11 '13 at 06:09
  • @JonathonReinhart: But I know that. I'm asking what's the most efficient way of doing exactly that. That "Hey, here's some data", should it be in a different port? – LightStriker Jul 11 '13 at 06:10

2 Answers2

1

I think it is better to use an object mechanism and send data in an interleaved fashion. This mechanism may work faster than multiple port mechanism.

eg:

class Data { DataType, - (Adio/Video) Size, - (Size of the Data buffer) Data Buffer - (Data depends on the type) }

'DataType' and 'Size' always of constant size. At the client side take the 'DataType' and 'Size' and then read the specifed size of corresponding sent data(Adio/Video).

Rahul B
  • 107
  • 6
  • But the size is never constant from one frame to another. Are you saying I should be wasting bandwidth to have a constant object size? – LightStriker Jul 11 '13 at 06:12
0

Just making something up off the top of my head. Shove "packets" like this down the wire:

1 byte - packet type (audio or video)
2 bytes - data length
(whatever else you need)
|
|  (raw data)
|

So whenever you get one of these packets on the other end, you know exactly how much data to read, and where the beginning of the next packet should start.

[430 byte audio L packet]
[430 byte audio R packet]
[1000 byte video packet]
[20 byte control packet]
[2000 byte video packet]
...

But why re-invent the wheel? There are protocols to do these things already.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328