hi ppl .. i did a program for bitstuffing..the client will get the frames ,append it with start and end frames("01111110") and send it to the server along with stuffing it(adding a zero after five 1's)...the server has to unstuff it by removing the extra starting and end frames and the extra zeros added..if i give small inputs it works but for large inputs it ends up in an infinite loop..pl help

server

client

Could you give me an example of a short frame for which bit-stuffing is necessary? Do your programs work with such a message?

I'll give you one: a message consisting of the three ASCII characters "a?b" (Hex values are 0x61, 0x3f, 0x62.)

How many bits must be transmitted in the message frame (including starting and ending frame sync bytes)?
How many bytes?
What are the bytes?
Does your client program transmit the correct number of correct bytes for this message?
Does the server handle the frame correctly?

Instead of getting muddled in the client-server aspects of the communication, have you tried simply writing the bytes of the frame to a file with the "client" program and reading the file with the "server" program. Note that with bit-stuffing, you might end up with some non-ASCII characters, so simply printing the bit-stuffed message bytes might or might not be enlightening. That's why short messages are important for testing. You can actually print out the bits of each message byte before and after stuffing to see what the program did with them.

This may help you separate the bit-stuffing functionality from the sockets stuff, and should make it easier to test.

Regards,

Dave

Footnote:
As a practical matter, I question the efficacy of doing bit-stuffing at the message level (it's usually done at the PHY level so that the higher communications layers don't have to be changed if/when the characteristics of the physical channel change. For example Ethernet has its own way of assuring signal integrity regardless of the nature of the message. Similarly for WiFi, HDLC, etc. The program generating the message and handing it off to the communications channel never has to worry about bit-stuffing or other signal integrity measures.

As an exercise in programming, I like the idea of using bit-stuffing to make you think in terms outside the usual messages made up of "bytes in" and "bytes out". I do think that testing/debugging would be easier with file I/O rather than client-server communications.

I think it is very important to visualize what would make simple test cases (short messages with and without bit stuffing). Test with known messages for which you can manually (or mentally, or programmatically) create the exact bit streams to test against your program's behavior. Then (and only then) go for longer and longer messages.

But that's just me.

Hi!

1. Please use indentation! The code is painful to follow when I have to search for the bracket boundaries trying to understand the code.
2. The:
   
   Quote:

   CPP / C++ / C Code: if(b[i]=='0'&&b[i+1]=='1'&&b[i+2]=='1'&&b[i+3]=='1'&&b[i+4]=='1'&&b[i+5]=='1'&&b[i+6]=='1'&&b[i+7]=='0')

   is (in my opinion) over-complicated .. the following :
   
   CPP / C++ / C Code:

   if(  strncmp( &(b+i), "01111110", 8 )==0 )
   // edit::: <<< previous wrong,,actually should use binary safe version:
   if( memcmp( &(b+i), "01111110", 8 )==0 )
   

   is logically same but easier to understand... Ok not really error but just remind you ..
   
3. Then notice that your variable 'i' can increase until it is equal to (strlen(b) - 1) :
   
   Quote:

   CPP / C++ / C Code: while(i<strlen(b)) {

   But in the next if sentence you use "b[i+7]" to check it against '0'. So if already i==(strlen(b)-1) then "b[i+7]" is out of bounds! Of course this is not the reason for the infinite loop you reported because you only read the memory and luckily not write anything to the undefined area. However any operating even just reading undefined memory area is always a programming bug and must be corrected. Thus:
   (edited >>>)
   
   CPP / C++ / C Code:

   rlen = read(connfd,b,sizeof(b));
   while( i < (rlen - 8)  )
   {
   

4. I think your infinite loop might be created by:
   
   Quote:

   CPP / C++ / C Code: if(b[i]== '1') { if(count!=5) { printf("%c",b[i]); count++; i++; continue; } }

   see: If at runtime your variable "count" has value 5 and the bit in the current reading position is '1' (i.e. b[i]=='1' is true with current i) then the "i++" will never be executed and the "cursor position" is never moved forward. I doubt that is what you intend.
   
5. Please remove those "continue":s will you. The "while" and the "for" loops don't need any additional kicking for them to iterate. "continue" is just used in loops when you wish to jump to next iteration skipping the following lines which otherwise would be executed. If you have
   
   CPP / C++ / C Code:

   if( something==1 ) {
       do_do();
       continue;
   }
   else {
       foo();
   }
   

   the else branch is certainly not executed if the do_do() got executed so the continue is irrelevant and unwanted.
   
6. Finally some nagging about the use of "goto". C language certainly includes "goto" but it is recommendable to be avoided. There are some good reasons to use "goto" (e.g. some error handling code in functions ...ok. search tutorials for better explanations.. ) however ín your code context it just obfuscates:
   
   Quote:

   CPP / C++ / C Code: a: if (count!=5) { opfr[i][z++]=str[i][j]; count++; } else { opfr[i][z++]='0'; count=0; goto a; }

   Following would be more clear I think:
   
   CPP / C++ / C Code:

   if( count == 5 ) {
       opfr[i][z++] = '0';
       count = 0;
   }
   opfr[i][z++]=str[i][j];
   count++;
   

   which should do exactly the same thing.
   
7. Still I don't know what any of this code is actually supposed to do in the conceptual/definition level. (And sorry no time for more deep deduction now) but I hope this can be of some help to you.

edit>> Ok Dave was quick posting reply... and I also agree e.g. with the points about the data being binary... and therefore
is actually incorrect also. Sorry for my lapse.
edit2>> To handle it correctly the "read" function returns the amount of bytes actually read. So that value should be used instead of strlen. Furthermore function "recv" can be someways better than "read" because allows more control via usage of flags.
... quite a hotchpotch this.. but thanks for Dave for reminding me also about some important basics...