Re: Broken TCP/IP packets

On Apr 2, 3:58 am, Markus Zingg <m.zi...@xxxxxx> wrote:
But i wonder why it works for half of the
time? is there any way i can increase the success probability ?

If you wait long enough after sending your 20 bytes, it's likely that
the TCP stack on the sender side get's bored enough to send out the
data. But there is absolutely no guarantee that the 20 bytes are still
there on the recivers end. That said a gateway along the path could
reasemble segments or even more fragment them because the underlaying
transport mechanism requiers it. Ok, with only 20 bytes that's quite
unlikely but relying on such stuff would be an extremly bad idea.

On MCU side i'm not using interrupts to push the data over serial
line. Do you think using interrupts can improve the success rate?
AFAIK interrupt are more likely non-preemptive .

ali

Only if the timeing gets changed (see above). You could try to turn
off Nagle and use IOCTLs to set the PUSH flag but once more there is
no guarantee for sucess by doing so.

It's really easy. Call recv() in a loop up until you have 20 bytes
(asuming your pakets are always 20 bytes in size, else introduce a
marker or lenght information). Store in excess recived bytes for the
next call where you would want the next paket and return to the
caller.

HTH

Markus

Markus!
Thanks for valuable input and it was indeed helpful. I really
can't understand your Nagle point though i tried to search my hardware
vendor provided tcpip library but no luck so far. Anyways, i've tried
following approach to get by with broken packets but need to test it
tomorrow .

say buffer is char array wiht 128 size.

so the seriali2ethernet s/w should do:

if (serialData < 20) // as desired data is with length of 20 bytes
while(buffer != 128 )
{
fetch every single byte from serial port and store it in buffer array.
and flush the buffer once sentinel (buffer==128) is true.
}
else
send data to connected socket.

_______________________________________________________________________-

i think it would be worth discussing my app architecture as well so
here i go:

I have developed a VB demo app which is calling a C dll (dynamic link
library in windows world) for tcp/ip connectivity. The dll is
mulithreaded asynchronous tcp/ip server. Basically dll is no more than
a forwarder module that is getting data from one tcp/ip client and
making data available on windows messaging system for registered (proc
hooking stuff) apps. (Using windows messaging system for passing data
through dll to VB app) .

The converter (serial to ethernet and ethernet to serial) software is
acting just like a pipe while converting serial requests to tcp/ip
packets and tcp/ip to serial data.

ali

.