I thought we should discuss the server-client communication protocol so i started a separate thread since it must be the same in all of the servers and clients.
I think it should be something like the http protocol with numbers corresponding to a certain command (101=LOAD, 102=UNLOAD, 103=PLAY, 104=STOP .....)
what do you think?
/markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem with numbers is that you need to remember what number stands for what and its very easy to use the wrong number.
In my earlier works on sockets I always used short self-meaning strings for commands. That way you look at the string and know what the command is and mistakes arising out of using the wrong codes go down drastically.
Debugging also is very easy with this approach.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm writing down a few notes regarding the networking aspects of the project, some time has passed since I've dealt with networking, so
take it easy on me.
The way I see it, we don't need one protocol but two. We probably wont want the broadcasting server to open a single connection to
each client that tries to connect to it, suppose that a server will have something like 10,000 listeners at the same time - it will have to mean
that 10,000 sockets will be opened, and furthermore, that the music will be sent to each one of them! maybe I got it wrong, but it seems that
this is some sort of overload we should probably avoid.
So we should separate the communication protocols into 2:
1. The broadcasting protocol that should be a multicast protocol such as UDP - meaning that it will broadcast the audio to a single
address, and whoever wants to listen to it, will listen to that specific address. If UDP, or any other multicast protocol, are able to deal with
such a broadcast - then this SHOULD be the easy part in communication. Come to think of it, we might even want to have 2 multicast
addresses - one for the raw audio, and another for meta data (song name, performer, public text messages, etc).
2. The client/server protocol, which should be established for each communication aspect that is specific to a certain client (e.g. "give me
the broadcasting address", play list request, msg the DJ that he sucks, etc). Each time that a client needs to ask the server something that
is specific only to it - than a TCP (i guess) connection should be established, the data should be exchanged, and then the connection is
closed. It should be done with threads (C++ threads are a bit difficult to handle, no?), a bit like the web servers like Apache are handling
connections.
I saw that there were a couple of messages regarding the way the data should be exchanged - We should consider XML as a method to move the info described in (2) around: It`s very obvious and readable, and it is very (very!) flexible, so wont get stuck in the future, if we'll add a bit more complex messages.
The entire thing might look something like:
Sender: (It could be the server or the client, it doesn't really matter, though in the beginning, the server is the listener)
1. Generate XML containing the message.
2. Calculate the XML size.
3. Send the size.
4. Send the XML
Receiver:
1. Get the size.
2. Get the XML according to the size
3. Parse the message.
4. Do whatever you want with it.
Pretty standard, I guess.
Thats it, more or less. Like I said, it's been a while, and please remember the English is not my native tongue, so take it easy.
Omer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I dont think we are working on internet broadcasting protocols just yet, although you hae some good ideas.
I think up to this point the protocol we need to figure out is the control protocol.
From a standard studio point of view, the machine running the server is hooked up to all the sound hardware, the client merely controls the broadcasting server, ie it tells it what song to add to the playlist, when to play, when to stop, pause etc.
I'm not explaining it very well, but I hope that helps to give some idea of the earlier stages of the project. It could be expanded to encompass internet radio (which would be cool), but we are still getting the basics working (decoding audio files, controlling the broadcast server etc)
Chris.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought we should discuss the server-client communication protocol so i started a separate thread since it must be the same in all of the servers and clients.
I think it should be something like the http protocol with numbers corresponding to a certain command (101=LOAD, 102=UNLOAD, 103=PLAY, 104=STOP .....)
what do you think?
/markus
The problem with numbers is that you need to remember what number stands for what and its very easy to use the wrong number.
In my earlier works on sockets I always used short self-meaning strings for commands. That way you look at the string and know what the command is and mistakes arising out of using the wrong codes go down drastically.
Debugging also is very easy with this approach.
I'm writing down a few notes regarding the networking aspects of the project, some time has passed since I've dealt with networking, so
take it easy on me.
The way I see it, we don't need one protocol but two. We probably wont want the broadcasting server to open a single connection to
each client that tries to connect to it, suppose that a server will have something like 10,000 listeners at the same time - it will have to mean
that 10,000 sockets will be opened, and furthermore, that the music will be sent to each one of them! maybe I got it wrong, but it seems that
this is some sort of overload we should probably avoid.
So we should separate the communication protocols into 2:
1. The broadcasting protocol that should be a multicast protocol such as UDP - meaning that it will broadcast the audio to a single
address, and whoever wants to listen to it, will listen to that specific address. If UDP, or any other multicast protocol, are able to deal with
such a broadcast - then this SHOULD be the easy part in communication. Come to think of it, we might even want to have 2 multicast
addresses - one for the raw audio, and another for meta data (song name, performer, public text messages, etc).
2. The client/server protocol, which should be established for each communication aspect that is specific to a certain client (e.g. "give me
the broadcasting address", play list request, msg the DJ that he sucks, etc). Each time that a client needs to ask the server something that
is specific only to it - than a TCP (i guess) connection should be established, the data should be exchanged, and then the connection is
closed. It should be done with threads (C++ threads are a bit difficult to handle, no?), a bit like the web servers like Apache are handling
connections.
I saw that there were a couple of messages regarding the way the data should be exchanged - We should consider XML as a method to move the info described in (2) around: It`s very obvious and readable, and it is very (very!) flexible, so wont get stuck in the future, if we'll add a bit more complex messages.
The entire thing might look something like:
Sender: (It could be the server or the client, it doesn't really matter, though in the beginning, the server is the listener)
1. Generate XML containing the message.
2. Calculate the XML size.
3. Send the size.
4. Send the XML
Receiver:
1. Get the size.
2. Get the XML according to the size
3. Parse the message.
4. Do whatever you want with it.
Pretty standard, I guess.
Thats it, more or less. Like I said, it's been a while, and please remember the English is not my native tongue, so take it easy.
Omer
I dont think we are working on internet broadcasting protocols just yet, although you hae some good ideas.
I think up to this point the protocol we need to figure out is the control protocol.
From a standard studio point of view, the machine running the server is hooked up to all the sound hardware, the client merely controls the broadcasting server, ie it tells it what song to add to the playlist, when to play, when to stop, pause etc.
I'm not explaining it very well, but I hope that helps to give some idea of the earlier stages of the project. It could be expanded to encompass internet radio (which would be cool), but we are still getting the basics working (decoding audio files, controlling the broadcast server etc)
Chris.
Omer
We are now using a separate board to discuss things. Please visit this link for replies to your post
http://www.clbnet.co.uk/~temporal/index.php?a=topic&t=9