general advice needed on two issues!

[drewdaman]

hello..

i have some general issues i need some advice with. i'm not going to implement this right away, but would like to know how to do some of this stuff because i should keep it in mind while doing some more of the "basic grunt" work.

i have mutilple camclient, a single multithreaded server adn multiple clients. the camclients are comptuers with webcams. the server is a central poitn: both camclients and clients connect to it.

also, i have not yet made teh server multithreaded. i will do this later on. was told by teh boss to hold off on this for right now! so.. maybe its just that i'm still confused about multithreading.. but i think my questions are valid!

the camclients receive a request to transmit. when this request is received, a stream from a webcam should be transmitted to the server. my question is... if there are mulitiple clients who request a stream from the same camclient, how can i coordinate the client threads, so the camcleitn only sends the stream once. the same info being received from a particular camclient has to be sent to two different locations from different threads. in other words, it would be a waste to have two different sockets receiving the same info at the server. i would need two sockets to send out the stream, but not to receive.

also, once the streaming starts, and hte client wants to abort... i would like to send a message to the server. but the server is just sending continuously. can i use select or something to see if there is an incoming message while i'm sendnig in a loop?

thanks!
drew.

[j0nas]

If you're on a LAN, multicast (IGMP) would be the best (I think):
http://www.tack.ch/multicast/
http://msdn.microsoft.com/library/de...rogramming.asp

Multicast does not work very well on WANs. You may want to look into how BitTorrent sovled it.

[MikeAThon]

You might want to look to a protocol that's different from either TCP or UDP. The protocol is called RTP for "real-time transport protocol" and it's defined at RFC 1889 and RFC 1890.

RTP is related to RTSP, "real-time streaming protocol", but I'm not precisely certain on the full nature of the realtionship.

In general, RTP is a balance between the highly-reliable-but-slow TCP and the fast-but-lossy UDP. RTP puts a reliable layer over the top of UDP, and is specifically designed for multicast multimedia applications. As I understand it, the "reliability" does not include the ability to recover lost packets; rather, all you get is the ability to detect that packet loss has occurred. But this is still better than UDP, which doesn't even tell you when packet loss has occurred.

RTP also includes timestamp data so that all the packets that actually are recieved can be assembled into the correct order, and played back at the correct timing. In other words, just because you suddenly received a whole bunch of packets doesn't mean that you should play them back more quickly; they need to be played out at the rate indicated by the timestamp data (hence the meaning of "real-time" in RTP's name).

One benefit of RTP is that it supports multicast (UDP does too, but TCP does not).

There are many sites out there that describe RTP and give libraryies for its use. Try this one: http://www.cs.columbia.edu/~hgs/rtp/

Mike