FIRST BYTE LOST SYSTEMATICALLY ON CLIENT SOCKET

Hi all,
I'm having some problems with a socket client on Linux.
The client fails systematically when it try to receive data from a
server on Windows.
The server send messages(I'm sure about it) in the following way:
<1°BYTE><2°BITE>...<N°BYTE>; the client receive message data as
<2°BITE>...<N°BYTE> loosing the first byte.
If I debug the application simetimes it happens the client receive the
messages correctly but in a non-deterministic way.
Following you can take a look at the piece of code that implement the
receive:

BOOL rc = FALSE;
memset(buf, 0x0, LINE_ARRAY_SIZE);

if (socketDescriptor < 0)
return rc ;

int result = 0 ;
struct timeval tval ;
fd_set readset ;
FD_ZERO(&readset);
FD_SET(socketDescriptor, &readset);
tval.tv_sec = timeout ;
tval.tv_usec = 0 ;
int succ_max_socket_descriptor = socketDescriptor + 1 ;

result = select(succ_max_socket_descriptor, &readset, NULL, NULL,
&tval);
if (result == -1 )
{
cerr << "didn't get response from server?";
}
else if( result )
{
int data_read = read(socketDescriptor, (void*)buf, LINE_ARRAY_SIZE );
if( data_read == 0 )
{
cerr << "didn't get response from server?";
}
else
{
rc = TRUE ;
}
}
else
{
cerr << "didn't get response from server?";
}
FD_CLR(socketDescriptor, &readset);

cout << "Modified: " << buf << "\n";
*message_len = strlen( buf ) ;

return rc;



Is there anyone who has any idea about what is happening?
Thank you for your advices.

Mauro.

> FIRST BYTE LOST SYSTEMATICALLY ON CLIENT SOCKET

Please don't shout.

And what is socketDescriptor? Stream or datagram?

mauro wrote:

>Hi all,
>I'm having some problems with a socket client on Linux.
>The client fails systematically when it try to receive data from a
>server on Windows.
>The server send messages(I'm sure about it) in the following way:
><1°BYTE><2°BITE>...<N°BYTE>; the client receive message data as
><2°BITE>...<N°BYTE> loosing the first byte.
>If I debug the application simetimes it happens the client receive the
>messages correctly but in a non-deterministic way.
>Following you can take a look at the piece of code that implement the
>receive:
>
> BOOL rc = FALSE;
> memset(buf, 0x0, LINE_ARRAY_SIZE);
>
> if (socketDescriptor < 0)
> return rc ;
>
> int result = 0 ;
> struct timeval tval ;
> fd_set readset ;
> FD_ZERO(&readset);
> FD_SET(socketDescriptor, &readset);
> tval.tv_sec = timeout ;
> tval.tv_usec = 0 ;
> int succ_max_socket_descriptor = socketDescriptor + 1 ;
>
> result = select(succ_max_socket_descriptor, &readset, NULL, NULL,
>&tval);
> if (result == -1 )
> {
> cerr << "didn't get response from server?";
> }
> else if( result )
> {
> int data_read = read(socketDescriptor, (void*)buf, LINE_ARRAY_SIZE );
> if( data_read == 0 )
> {
> cerr << "didn't get response from server?";
> }
> else
> {
> rc = TRUE ;
> }
> }
> else
> {
> cerr << "didn't get response from server?";
> }
> FD_CLR(socketDescriptor, &readset);
>
> cout << "Modified: " << buf << "\n";
> *message_len = strlen( buf ) ;
>
> return rc;
>
>
>
>Is there anyone who has any idea about what is happening?
>Thank you for your advices.
>
>Mauro.
>
>
"Non-deterministic" usually means "buffer overflow". If I were you I
would check the rest of the code for arrays out of bounds.
Secondly, if you send/receive an array of unicode characters, integers
or other types (encoded in the char* buffer), then you should pay
attention to little-endian/big endian problems.

Mihai

PS: And, yeah - don't shout. It's rude.

if I put a sleep() between the select and the read the application
behave even worse loosing more data than the first byte.
I don't send any data but characters.
So... any idea about that?
Thanks...
I ask your pardon for crying so strong I'll be more kind next time...
thank you.


Mihai Osian wrote:
> mauro wrote:
>
> >Hi all,
> >I'm having some problems with a socket client on Linux.
> >The client fails systematically when it try to receive data from a
> >server on Windows.
> >The server send messages(I'm sure about it) in the following way:
> ><1°BYTE><2°BITE>...<N°BYTE>; the client receive message data as
> ><2°BITE>...<N°BYTE> loosing the first byte.
> >If I debug the application simetimes it happens the client receive
the
> >messages correctly but in a non-deterministic way.
> >Following you can take a look at the piece of code that implement
the
> >receive:
> >
> > BOOL rc = FALSE;
> > memset(buf, 0x0, LINE_ARRAY_SIZE);
> >
> > if (socketDescriptor < 0)
> > return rc ;
> >
> > int result = 0 ;
> > struct timeval tval ;
> > fd_set readset ;
> > FD_ZERO(&readset);
> > FD_SET(socketDescriptor, &readset);
> > tval.tv_sec = timeout ;
> > tval.tv_usec = 0 ;
> > int succ_max_socket_descriptor = socketDescriptor + 1 ;
> >
> > result = select(succ_max_socket_descriptor, &readset, NULL,
NULL,
> >&tval);
> > if (result == -1 )
> > {
> > cerr << "didn't get response from server?";
> > }
> > else if( result )
> > {
> > int data_read = read(socketDescriptor, (void*)buf, LINE_ARRAY_SIZE
);
> > if( data_read == 0 )
> > {
> > cerr << "didn't get response from server?";
> > }
> > else
> > {
> > rc = TRUE ;
> > }
> > }
> > else
> > {
> > cerr << "didn't get response from server?";
> > }
> > FD_CLR(socketDescriptor, &readset);
> >
> > cout << "Modified: " << buf << "\n";
> > *message_len = strlen( buf ) ;
> >
> > return rc;
> >
> >
> >
> >Is there anyone who has any idea about what is happening?
> >Thank you for your advices.
> >
> >Mauro.
> >
> >
> "Non-deterministic" usually means "buffer overflow". If I were you
I
> would check the rest of the code for arrays out of bounds.
> Secondly, if you send/receive an array of unicode characters,
integers
> or other types (encoded in the char* buffer), then you should pay
> attention to little-endian/big endian problems.
>
> Mihai
>
> PS: And, yeah - don't shout. It's rude.

Your socket is a stream, there is no guarantee it will come out in the same
units as the server put it in. You should also protect your read() calls
against interrupts.

I would run the client with strace and look at what that shows. Verify that
the server is really sending the data you think it is using ethereal.

In article <41c16ad6$0$26970$(E-Mail Removed)>,
(E-Mail Removed) (Simon J. Rowe) writes:

>And what is socketDescriptor? Stream or datagram?

And have you set it nonblocking? I presume you have; otherwise
you wouldn't need that select() call. I've never tried using
select() with a blocking socket; I don't know what it would do.

Have you tried using recv() rather than read()? Again, I've never
used read() with sockets, so I don't know what it would do.

--
/~\ (E-Mail Removed)lid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Simon J. Rowe wrote:
> Your socket is a stream, there is no guarantee it will come out in
the same
> units as the server put it in. You should also protect your read()
calls
> against interrupts.
>
> I would run the client with strace and look at what that shows.
Verify that
> the server is really sending the data you think it is using ethereal.

The TCP protocol should be a safe protocol. The first call to read()
instruction should return at least the leading bytes of the messages
and not loose them; it would be possible to loose the ending bytes but
not those in the head.
What do you mean when you say that I should protect the read() calls
from interrupt?

"Mauro" <(E-Mail Removed)> writes:

> Simon J. Rowe wrote:
> > Your socket is a stream, there is no guarantee it will come out in
> the same
> > units as the server put it in. You should also protect your read()
> calls
> > against interrupts.
> >
> > I would run the client with strace and look at what that shows.
> Verify that
> > the server is really sending the data you think it is using ethereal.
>
> The TCP protocol should be a safe protocol. The first call to read()
> instruction should return at least the leading bytes of the messages
> and not loose them; it would be possible to loose the ending bytes but
> not those in the head.
> What do you mean when you say that I should protect the read() calls
> from interrupt?

It means that all caller of a I/O syscall on unix should check the
result and errno and if it's EINTR, it should recall to continue the
I/O.

--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"

tell you what, chop all this code down and make two simple apps that only do
the reading and writing on the socket. Provide the code here (as two
separate .c or .cpp files) and I'll be happy to debug it myself. Make the
server listen and upon connection transmit bytes. Client connects, reads,
writes it to screen and exits.

It's too hard for us to second guess what's going on and we don't have the
server code and it looks like there's more to the client code that whay you
show here. More than likely when you create the above apps you'll find your
problem doesn't exist in that code and you'll see what the problem is.