Re: Broken TCP/IP packets

Tech-Archive recommends: Fix windows errors by optimizing your registry

In your TCP layer add packetization overhead and then decode it
in the other end. With TCP you have no guarantee for the receive
sizes because TCP is a stream.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Ali" <abdulrazaq@xxxxxxxxx> wrote in message
news:1175420831.870106.313590@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have a serial device that is using MCU's UART (rs232) for data
transfer, every time my device is suppose to deliver 20 bytes making
it a single transaction. We have a VB and C# app using MSCOMM and it
works perfectly.
Now I have added an Ethernet converter to convert serial data to TCP/
IP packets. It works atleast for half of the time. For the rest of
the problematic half the behavior is very strange, yes, my received
packets are broken in parts. For example I'll receive 20 bytes in tow
transactions like 10 byte for each time. I tried to look at the MCU
UART signal via oscilloscope but the timing was quite consistent.
Can't understand why packets are broken/scattered, any idea? where is
should be lookin?

The TCP/IP is using simple send function upon the arrival of serial
data. Is there anything that i can do with time out or anything else?

regards,
ali



.

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Broken TCP/IP packets
    ... it a single transaction. ... packets are broken in parts. ... You cannot expect TCP to give you pakets on the remote end the way you ... segments to what ever degree seems good to get a good performance. ...
    (comp.arch.embedded)
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
    (freebsd-performance)