🚀 go-pugleaf

Hi,

In an effort to make a client/server pair for streaming MP3's over TCP/IP
(another one?!), I ran into a strange problem.

First, I've created a server and client that write and read one character at
a time. This worked fine, but was very slow. Next, I've adapted the server
software so that characters are first loaded in a string and then written to
the socket. This still worked fine with the 1 character read client. The
performance was better too, but still no good enhough.

When I tried to adapt the client to read more than one character a time, I
bumbed into the problem. Each time a file it streamed, it keeps changing in
size.  The size changes arbitrary between 20 and 200 bytes over the original
size, never under the original size.  When I play the file, many errors are
reported by the mp3 player (mpg123), but the player still manages to decode
to a somewhat recognisable song, but with many interruptions and a kind of
distortion.  So not only is the file (slightly) bigger as it should be, it
is also (slightly) transformed during the process of streaming (or reading).

This is the server write bit:

    if ( (fp = fopen( "/root/in", "r")) != NULL ) {
     while ( !feof(fp) ) {
      counter = 0;
      for ( i = 0; i < DATAGRAM_SIZE; i++ ) {
       if ( !feof(fp) ) {
        message[i] = getc(fp);
        counter++;
       }
      }
      write(slaveSocket,
       message,
       counter);
     }
     fclose(fp);
    } else {
     fprintf(stdout, "Error opening file\n");
    }

This is the client read bit:

 while ( 0 < (status = read(clientSocket,
  buffer, sizeof(buffer) - 1)))
 {
  for ( i = 0; i < (sizeof(buffer) - 1); i++ ) {
   putc( buffer[i], stdout );
  }
 }


The read-one-character-at-a-time client works fine with the above server
bit. The read bit looks like this:

  while ( 0 < (status = read(clientSocket,
   buffer, 1)))
  {
   cr = buffer[0];
   putc(cr, stdout);
  }

Any suggestions to fix this strange behavior are very welcome, or is this
one for the X-Files?

Thanks a lot

Steven Devijver
(steven.devijver@cmpmail.com)
Please send replies via email too. thanks.