Choice 1: audio, a simple audio client server system

Transcription

1 Choice 1: audio, a simple audio client server system The objective of this practice is to complete the program audiosimple which we have presented in practice 0. The new program, called audio, allows the sending of audio data from a file, which has been recorded previously, to a client located on a remote machine. Therefore, two new functions have to be included into audio in addition to the already known ones for recording and reproducing: server and client. First, we must start a server on a given machine. Then, a client will be started in another system, initiating a TCP connection with the server, through which control information will be exchanged (name of the file requested by the client, data port to be used, etc.). The TCP connection can also be used by the server to send some initial data to the client, allowing the client to have a buffer to isolate the playing process from possible delays in the network. Once these data have been sent, the server will reach the stable operation regime, in which it will use UDP to send data to the client at regular intervals. The sending of data at regular intervals results in memory savings at the client. The communication will finish when the file has been read completely at the server, or when an user requests it at either client or server; in any case, the system detecting this occurrence will inform the other system using the TCP connection. Next we describe the architecture of the practice, detailing some design decisions that you should implement. Modify the behaviour of the record operation in order to confer the semantic (type) of the generated audio content. To achieve this, you will store in the same file the following information: the number of utilized bits per sample the number of channels used (1 if mono, 2 if stereo) the sampling frequency. and the - character as delimiter Store this information as ASCII text (you can use any function member of the printf family). For example, a file with the previous format could be as follows: ^@^@<FF><FF><FF><BF><FF><FF><C3><CF><D7><E3><E6><D2>^R<D3><90><D6> <E0><E3>4<D7>(<DB><FF><D7>{<E2>^U<D7>T<DD><95><D3><B6><DC><C6><D1><BB><D9 >^C<D6>^Q<DE><F5><D5>^@<DE>F<D7><BA><DE>^@<D7>'<DF><A5><D5>^U<DD><F4> Do not worry about the strange characters: this is sound data, and therefore, difficult to print Note that you can check the contents of a file like this by means of the hexdump command. For the data exchange, the protocol is as follows: All the information will travel as ASCII text (i.e., you can use some of the printf and scanf functions to compose and interpret the messages). Knowing that the TCP service is a byte stream, it is necessary to insert message delimiters at the beginning of each command with additional information about message size. The encoding of the length information can be in decimal, with at minimum 3 digits, filled with 0 if the size value occupies one or two digits, followed by a space which separates the length of message. In order to implement it, one can use printf and scanf with format indicator %02d. For interpretation of the message, you can first read 4 characters, in which the length is encoded and the space the length information from the rest of the packet, and next the complete command. The length of the bytes read represents the remaining length of the message (i.e. without counting the three bytes of length information, nor the separating space character). The commands defined in this way are the following: The client will send the name of the requested file in a string that starts with the text (preceeded with LLL representing the encoded length information) LLL CLIENT:STARTING filename eg:028 CLIENT_STARTING mymusic The server will open the file, and if everything is OK, it will answer with a message LLL SERVER:CONTENT_PARAMETERS, followed by the number of bits, the number of

2 channels, the frequency of the content as well as the sequence number which will be used to send the first data packets over UDP. ex: 045 SERVER:CONTENT_PARAMETERS If the server cannot open the file, or the file do not have an appropriate format (it is not possible to identify the parameters written in the file), it returns LLL SERVER:PARAMETER_ERROR and the name of the file ex: 039 SERVER:PARAMETER_ERROR mymusic Then the client issues a message: LLL CLIENT: TRANSMISION_PARAMETERS message to specify the port in which the client is expecting to receive UDP packets, number of audio bytes to be received on each UDP packet (not including any other information such as numbering, time-stamps, etc)., and the number of bytes to be buffered in the client ex: 45 CLIENT: TRANSMISION_PARAMETERS The server answers sending the data required to fill the buffer after a SERVER:DATA indication followed by bytes (if we continue with the previous example). This message is not delimited, because the size of the channel SERVER:DATA is known in advance (a priori), as well as the total size of bytes to be transferred, thanks to information conveyed in the previous message. ex: SERVER:DATA <FF><FF><FF><BF><FF> Note1: The data is directly encoded in octets, without the need to convert to decimal or hex. More precisely <FF> occupies ONE octet. In this part printf function is not used.instead the data is sent from the memory pool, in which the audio data is stored. Note2: the reason why TCP is used to send this data is because TCP offers a flow control service, that is nice for high speed communication between two systems that can be very heterogeneous. If UDP were used, depending on the sending rate and on the capacities of the receiver, packets could get lost. Once all the data has been received, the client answers with a CLIENT:WAITING_FOR_STREAMING (also without delimiters), after which the server can start sending audio data through UDP After this phase, the client will start playing the audio, and the server will start the periodic transmission of data using UDP. For now on, the control connection will only be used to send a 025 CLIENT:COMMUNICATION_END if the file transmission is already in progress, or 033 CLIENT:INTERRUPTION_COMMUNICATION or 034 SERVER:COMMUNICATION_END, if the file was completely read or if the end of the application was requested by pressing CTRL-C on each one of the systems (client or server). When the SERVER:COMMUNICATION_END occurs the client discards all the data which is still in the memory of the sound card while a new message COMMUNICATIONS_END at the client, sound playback stops. Regarding to the client architecture during the periodic play-out phase, it is required to isolate the network data reception from the soundcard data delivering, in order to be able to use asynchronously the data when the network suffer delays (otherwise, the blocking of the code waiting for a network packet would result in available data blocks not delivered to the soundcard). It is also required to isolate the control session that uses the TCP connection from the rest of the tasks taken care by the code (we will isolate it although considering the vague timing requirements information transmitted over TCP, this would not be strictly required, since the user would not notice delays if the control processing took care at the same time in which, for example, data were sent to the sound card. In order to make independent the tasks in the client, we recommend the use of a single execution thread controlled by select. In this model there is a single process that gets block waiting for the first of a set of events (specified in the call to select. The code just has to react to the events that can unblock the process (arrival of a data packet from the network, arrival of a SERVER:COMMUNICATION_END or SERVER:COMMUNICATION_END, expiration of the timer that signals the sending of more data to the sound card). An alternative design, not recommended due to its higher complexity, is to use several threads or processes. Note that it is not acceptable in any case to use active wait - a code that continuously loops checking in a non-blocking fashion the occurrence of an event-, since this design poses significant performance problems. The buffer that holds data that has been received from the network, but has not delivered yet to the soundcard is a ring buffer, in which information pointing to the first data block to be sent to the soundcard and to the first empty block is stored. Since the code will only have a single execution thread, it is not required to use semaphores to protect the access to the ring buffer.

3 In the server, the architecture for the periodical data sending will consist of a single process that will use select to send data to the destination and to wait to the possible reception of a CLIENT: COMMUNICATION_END message. The server must send the data in regular intervals so that the client is not required to accumulate data in memory. The server sends as many data as necessary to maintain the play-out of the content for the time between two successive data packets. This behavior is possible due to the knowledge that the server is supposed to have about the semantics of the content (i.e., that it is a continuous audio flow with a certain encoding, sampling rate, etc.) The server must send the data in regular intervals so that the client is not required to accumulate data in memory. The server sends as many data as necessary to maintain the play-out of the content for the time between two successive data packets. This behavior is possible due to the knowledge that the server is supposed to have about the semantics of the content (i.e., that it is a continuous audio flow with a certain encoding, sampling rate, etc.). For example, if the size of the audio payload carried in an UDP packet is 256 bytes, and it contains data corresponding to a 16 bit, stereo, 8000 Hz sampling frequency, therefore holding play-out for 16 milliseconds, then the server will send one of this packets each 16 milliseconds. In this case it is not required to perform flow control, since the sending speed is low enough (in the example considered above, 64 Kbps) so that it will not generate any problem in any of the architectures in which this program is going to be executed. In order to not accumulate possible delays in the sending of data through the network, the estimation of the time in which the server process should awake will consider the starting time of the regular sending, adding to this time the ideal play-out time for the packets that have been sent up to that time. Ie., if the time in which the regular sending begun (suppose that the client did not require accumulated data) is t 0, the play-out of a packet holds for T seconds, and packets number 0, 1, 2 and 3 have been sent, then packet number 4 should be sent at time t 4 = t 0 +4*T. The select function programmed to activate the process will be configured to sleep for t 4 currenttime seconds. Take into account that UDP packets can be lost (but assume that they cannot be re-ordered). To identify the lost packets, you must incorporate information about packet numbers into the packets. Even though you could use a proprietary format to do so, you are requested to utilize the RTP format for this purpose 1. You must implement correctly all the header parameters that are described in the standard, with the following considerations: For the RTP packet, use the L8, or L16 with one single channel at Hz payload types, defined in RTP profiles for audio and video (RFC3551), sections , y 6, that are linear codifications 2. Of course, the recording of the contents would have been performed according to the parameters corresponding to any of the Payload Types commented above. And for the timestamp, take into account the recommendations which exist in RFC3551: The timestamp of the RTP header of a packet is related to the first sample included in the packet, and the frequency used to mark the packets is the same as the one used for sampling. That means, that if a packet contains 128 samples and the packet has a timestamp of 3300, the following packet will have a timestamp of For the other packet header fields like SSRC, use the value 0. Take into account that in order to make your packets conformant to the RTP standard, you must respect the byte order convention for sending data over a network, which is network byte order or Most Significant Byte. This is in contrast to what we use in our Linux machines, so that you should use the functions htonl, htons and their inverses ntohl and ntohs appropriately. (Get information about them from the manual. Think about it: if the data are 8 bits, what function do you have to use to change the byte order of the data (hint: With 8 bits, is it really necessary to change the byte order?)). Moreover, you must transport the data itself using an appropriate byte order (so that they can be received by architectures with a different byte order and can be reconstructed in the correct way). Therefore, you must use conversion functions if data are recorded in a 16 bits format. In the client, during the play-out of the audio data, packets which arrive than the expected time of playout will be discarded. If the packet has arrived at proper time, it is written in the ring buffer. Next, the 1 Note that you are requested to use RTP, but not RTCP, whose implementation is more complex. 2 Since for L8 it is not defined neither the Payload Type number nor the sampling frequency, take the following values: Payload Type = 100; sampling frequency= 8000 Hz.

4 select call is used to try to write in the sound card all the packets available in the ring buffer, until the internal buffer of the soundcard is full, in which case the writing process will be blocked. In this case, select can awake to serve packet reception from the network, or the availability of new space in the sound card. When no audio data is available, the application sleeps until the theoretical time for play-out, time at which if there is still no audio data available, the last packet received will be repeated (note that if a packet would have arrived in the meantime, the code would have entered in a writing sequence in the select in the and timer would not have timed-out). In order to not accumulate delays, the estimation of the expiration time of the timer programmed to wait until the next time to play-out a missing packet will take into account the starting time of the play-out, adding to this the ideal play-out time of the packets that would have been received up to that time (see the previous explanation for the timing of the sending process at the server). After a client is served, the server will finish its execution (it is not required to attend multiple clients neither concurrently nor sequentially). Después de atender un cliente, el servidor finalizará su ejecución (no es necesario atender múltiples clientes ni simultanea ni sucesivamente). The command line interface of the program shall be as follows: audio record [-b(8 16)] [stereo] [-vvol] [-ddur] [-ffre] file audio play [-vvol] [-ddur] file audio server [ c] [ qloss] servertcpport audio client [-c] [-vvol] [-llen] [-kaccumulationtime] file servername servertcpport clientudpport With c (verbose mode), a trace is shown showing the main TCP exchanges, and in the periodic phase one point is printed each time a packet is sent (server) or a packet is written to the audio device (client). If a packet has not been received, the client will write an X. If a packet arrived later than expected and was discarded, the client will write an R. When the application finishes, it will be shown the theoretical time required for reproducing the content received, and also the time effectively used since the play-out of the first packet until the last one (or a good approximation of this time); the comparison among these times can be used to estimate the quality of an implementation. The option -l allows to specify the length in bytes of the audio data sent in the packets. The default value is The option d allows specifying the duration of the play-out in milliseconds. If it is not indicated or set to 0, the play-out shall continue until the end of the sent content. With k you can indicate the time in milliseconds that would take to play-out the data which the sender sends using the TCP connection to the receiver at the beginning of the play-out sessions. For this purpose, the client accumulates the data in a buffer, which it has allocated before, to be able to compensate variations in the network delay. This buffer should be larger enough to store 2000 milliseconds more than the buffering time specified in this command. By default, 3000 milliseconds will be the accumulated time. The option qloss, allows specifying a certain percentage of packets, which will not be sent by the server (they are discarded), so that a scenario with packet loss can be simulated. LOSS shall be a number between 0 and 20, and indicates, that LOSS packets of each 20 sent packets shall be dropped. The lost packets are the LOSS first of each sequence of 20 packets (this way, the result is perfectly repeatable). The default value is 0 and indicates that no packets are lost. If the verbose mode is activated, write an X for each dropped packet. The functionality of q allows to verify the behavior of your code in presence of packet loss (that it does not continue to play-out as defined etc). To verify that the RTP format has been generated correctly (taking into account the usage of byte-order converters etc.), implement the following modification in the client: if the indicated port in the parameter

5 clientdataport is 0, this shall lead to the fact that the UDP socket is not activated (even though the exchanged information with the server indicates that the utilized port should be 5004, the default port for UDP). If the UDP port is not open by audio, other application (in this case rtpdump could do) Once you have done this, you could verify the code in the following way: Start the server in the normal way Start the program rtpdump (see rtpdump h) on the client machine, indicating that it shall listen to port Start your client code also on the client machine with clientdataport 0. The client will be started, and will exchange messages with the server. However, it will not play-out any audio data, because the code, which is really listening to the data on the indicated port, is rtpdump. As a result, you will see the received packets in each moment and if the used format is conformant to the RTP specification (sequence numbers must increase by one, and timestamp increases must be appropriate). As a help for debugging the code, we remind you to observe the ports (UDP and TCP), which you use in the following way: Execute netstat atu > file1 before you start the program and netstat atu > file2 afterwards. Execute diff file1 file2 and obtain one or several ports which are used by your program. strace can also show you valuable information about the utilized ports. Notes To be able to compile the functions log and pow from the library configsound.c, take into account the following: For the compilation, the line #include <math.h> has been included, which enables the compiler to know the header declarations. But this is not sufficient: it is necessary to know at the time of linking where this function is located. The linker searches in a certain number of libraries, but not in all. One of the libraries in which it does not search for function names by default, is the mathematical library (libm). To make the linker search in that library as well, you must indicate AT THE END of the linking command, that the linker shall look into the libm library after the functions log and pow. This can be achieved with the option -lm. Similarly, you have to add the option -lsocket if you want to make the linker look for function names in the socket library, etc. Improvements As improvement, it is proposed to make a new version (called audio6) which allows communicating using IPv6. Therefore, you must modify the module in which the connections are realized and adapt the data types, which are used in your code, to store the information related to IP addresses. A more advanced improvement could be that the code can work with both, IPv4 and IPv6. Appendix You can find the code to process the command-line arguments on the web page of the lecture.