windows socket problem

[M. Schloenvoigt]

Hi,

I've implemented an network application using win sockets with TCP/IP
protocol. It works fine and I could send and receive messages with it.
But one following problem couldn't solved yet: The server app should
send messages permanently (e.g. each ms). Not that problem. But the
client app should update the message handler only each 5 ms, because it
is bind to an intern message loop that runs with 30 fps. So, when I send
ten messages to the client, only three or sometimes four messages will
be received. I'm sure that it is guaranteed that my app will
receive all messages sent to it when I'm using a TCP connection. But in
this case it seems to me that messages will be overwritten if they are
not fetched before the next arrived. Are there any option I have to set
or is it not possible to get this dropped messages?

Thank you in advance for your attention in this matter, Marcel.

[Arkady Frenkel]

That sound very strange that you succeed send each 1 ms, because system
shedular run each 10-15 ms and during that time all threads in the system
are treated. So even you have the slice for sending you'll be interrupted
for system to work , In windows CE you have 1 ms interrupt but system have
to do it's job too, so you never have stable 1 ms interrupt even in RT OS
like windows CE
Arkady

Post by M. Schloenvoigt
Hi,
I've implemented an network application using win sockets with TCP/IP
protocol. It works fine and I could send and receive messages with it. But
one following problem couldn't solved yet: The server app should send
messages permanently (e.g. each ms). Not that problem. But the client app
should update the message handler only each 5 ms, because it is bind to an
intern message loop that runs with 30 fps. So, when I send ten messages to
the client, only three or sometimes four messages will be received. I'm
sure that it is guaranteed that my app will
receive all messages sent to it when I'm using a TCP connection. But in
this case it seems to me that messages will be overwritten if they are not
fetched before the next arrived. Are there any option I have to set or is
it not possible to get this dropped messages?
Thank you in advance for your attention in this matter, Marcel.

[M. Schloenvoigt]

Post by Arkady Frenkel
That sound very strange that you succeed send each 1 ms, because system
shedular run each 10-15 ms and during that time all threads in the system
are treated. So even you have the slice for sending you'll be interrupted
for system to work , In windows CE you have 1 ms interrupt but system have
to do it's job too, so you never have stable 1 ms interrupt even in RT OS
like windows CE
Arkady

Post by M. Schloenvoigt
Hi,
I've implemented an network application using win sockets with TCP/IP
protocol. It works fine and I could send and receive messages with it. But
one following problem couldn't solved yet: The server app should send
messages permanently (e.g. each ms). Not that problem. But the client app
should update the message handler only each 5 ms, because it is bind to an
intern message loop that runs with 30 fps. So, when I send ten messages to
the client, only three or sometimes four messages will be received. I'm
sure that it is guaranteed that my app will
receive all messages sent to it when I'm using a TCP connection. But in
this case it seems to me that messages will be overwritten if they are not
fetched before the next arrived. Are there any option I have to set or is
it not possible to get this dropped messages?
Thank you in advance for your attention in this matter, Marcel.

Thanks for your fast reply. The main problem is not the fast sending of
pings from the server but the time shift between sending and receiving
network messages. I ever lost messages if the interval of receiving is
bigger than the interval of sending. And so I ever lost information like
described in my small example from above. But this fact conflicts with
the term that a TCP connection ever ensures a lossless transit of each
packets. Any ideas for a good approach to solve this problem?

Marcel

[Arkady Frenkel]

That not TCP problem IMHO , but during fast copies from user mode to kernel
causes dropping the messages yet on that period so tcp stack in advance send
only partial data. You can check that with sniffer , to see if all data send
or only part of it.
Arkady

Post by M. Schloenvoigt

Post by Arkady Frenkel
That sound very strange that you succeed send each 1 ms, because system
shedular run each 10-15 ms and during that time all threads in the system
are treated. So even you have the slice for sending you'll be interrupted
for system to work , In windows CE you have 1 ms interrupt but system
have to do it's job too, so you never have stable 1 ms interrupt even in
RT OS like windows CE
Arkady

Post by M. Schloenvoigt
Hi,
I've implemented an network application using win sockets with TCP/IP
protocol. It works fine and I could send and receive messages with it.
But one following problem couldn't solved yet: The server app should send
messages permanently (e.g. each ms). Not that problem. But the client app
should update the message handler only each 5 ms, because it is bind to
an intern message loop that runs with 30 fps. So, when I send ten
messages to the client, only three or sometimes four messages will be
received. I'm sure that it is guaranteed that my app will
receive all messages sent to it when I'm using a TCP connection. But in
this case it seems to me that messages will be overwritten if they are
not fetched before the next arrived. Are there any option I have to set
or is it not possible to get this dropped messages?
Thank you in advance for your attention in this matter, Marcel.

Thanks for your fast reply. The main problem is not the fast sending of
pings from the server but the time shift between sending and receiving
network messages. I ever lost messages if the interval of receiving is
bigger than the interval of sending. And so I ever lost information like
described in my small example from above. But this fact conflicts with the
term that a TCP connection ever ensures a lossless transit of each
packets. Any ideas for a good approach to solve this problem?
Marcel

[M. Schloenvoigt]

Post by Arkady Frenkel
That not TCP problem IMHO , but during fast copies from user mode to kernel
causes dropping the messages yet on that period so tcp stack in advance send
only partial data. You can check that with sniffer , to see if all data send
or only part of it.

I've checked outgoing data with a sniffer application and realized that
all bytes have been send. At the remote station some packets doesn't
received as always. One thing now is certain: The problem isn't on the
sending part. Your prompt reply has been appreciated. Marcel

[Michael K. O'Neill]

Post by M. Schloenvoigt

Post by Arkady Frenkel
That not TCP problem IMHO , but during fast copies from user mode to kernel
causes dropping the messages yet on that period so tcp stack in advance send
only partial data. You can check that with sniffer , to see if all data send
or only part of it.

I've checked outgoing data with a sniffer application and realized that
all bytes have been send. At the remote station some packets doesn't
received as always. One thing now is certain: The problem isn't on the
sending part. Your prompt reply has been appreciated. Marcel

TCP indeed is guaranteed delivery. If all data is sent, then probably the
problem is coding of the recipient side. Remember, TCP can (and often does)
coalesce several send's into a single receive. For example, your sending
side might send out three chunks of data, but your recipient side might get
all three in a single call to recv(). Your code must be prepared to deal
with this, which is ordinary/normal.

[Arkady Frenkel]

But Marcel wrote that all data send but not all received as both sniffers
show , but that is really strange because if receiving side not received
some packet it have to notify sending peer for re-send about that.Do you see
that, Marcel, just a hint about direction ...
Arkady

Post by Arkady Frenkel

Post by M. Schloenvoigt

Post by Arkady Frenkel
That not TCP problem IMHO , but during fast copies from user mode to

kernel

Post by M. Schloenvoigt

Post by Arkady Frenkel
causes dropping the messages yet on that period so tcp stack in advance

send

Post by M. Schloenvoigt

Post by Arkady Frenkel
only partial data. You can check that with sniffer , to see if all data

send

Post by M. Schloenvoigt

Post by Arkady Frenkel
or only part of it.

I've checked outgoing data with a sniffer application and realized that
all bytes have been send. At the remote station some packets doesn't
received as always. One thing now is certain: The problem isn't on the
sending part. Your prompt reply has been appreciated. Marcel

TCP indeed is guaranteed delivery. If all data is sent, then probably the
problem is coding of the recipient side. Remember, TCP can (and often does)
coalesce several send's into a single receive. For example, your sending
side might send out three chunks of data, but your recipient side might get
all three in a single call to recv(). Your code must be prepared to deal
with this, which is ordinary/normal.

[M. Schloenvoigt]

Post by Michael K. O'Neill
TCP indeed is guaranteed delivery. If all data is sent, then probably the
problem is coding of the recipient side.

After a long and serious debugging period, I've detected the error. It
was not easy finding the problem after trying several methods without
any result. The problem really was coding of the recipient side.

Post by Michael K. O'Neill
Remember, TCP can (and often does)
coalesce several send's into a single receive. For example, your sending
side might send out three chunks of data, but your recipient side might get
all three in a single call to recv(). Your code must be prepared to deal
with this, which is ordinary/normal.

As I described in my entire mail, the messages will be overwritten if
they are not fetched before the next message arrived and so I received
more than one chunk in a single message. Also the chunks are seperated
by an delimiter ('\0'). That wasn't apparent for me because the buffer
of incoming data was cast to an string right after calling recv(). As I
tried to cast a line of characters with more than one deliminiter in it
then even the first part up to the delimiter was assigned to the target
string. And so I've got a notion that only one message arrived.

Thank you in advance for your attention in this matter, Marcel.

[Arkady Frenkel]

Oh, nice. From you last message I thought that receiving peer didn't catch
the data , but it do receive it, but app failed to treat it...
Best wishes
Arkady

Post by Michael K. O'Neill
TCP indeed is guaranteed delivery. If all data is sent, then probably the
problem is coding of the recipient side.

After a long and serious debugging period, I've detected the error. It was
not easy finding the problem after trying several methods without any
result. The problem really was coding of the recipient side.

Post by Michael K. O'Neill
Remember, TCP can (and often does)
coalesce several send's into a single receive. For example, your sending
side might send out three chunks of data, but your recipient side might get
all three in a single call to recv(). Your code must be prepared to deal
with this, which is ordinary/normal.

As I described in my entire mail, the messages will be overwritten if they
are not fetched before the next message arrived and so I received more
than one chunk in a single message. Also the chunks are seperated by an
delimiter ('\0'). That wasn't apparent for me because the buffer of
incoming data was cast to an string right after calling recv(). As I tried
to cast a line of characters with more than one deliminiter in it then
even the first part up to the delimiter was assigned to the target string.
And so I've got a notion that only one message arrived.
Thank you in advance for your attention in this matter, Marcel.