Re: RST In video streaming over TCP socket?

[Anders Broman <anders.broman () ericsson com>]

Hi,
And this article may explain the oversized packet(s)
http://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html

Regards
Anders

From: wireshark-users-bounces () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of Jaap 
Keuter
Sent: den 7 februari 2017 07:51
To: Community support list for Wireshark <wireshark-users () wireshark org>
Subject: Re: [Wireshark-users] RST In video streaming over TCP socket?

Hi,

Just throwing out some ideas here, but it seems you run into some fundamental differences between UDP and TCP.
Without going to write a complete textbook on it (read Stevens, et. al. for that) here’s some insight.
UDP transport gives you nice message (datagram) based transport. That means that each UDP packet contains just that, 
one message.
TCP transport gives you a stream based transport. That means that each TCP packet is just there to transport a data 
stream, which may be any slice of one or more messages.
Since your solution is based on sending defined messages the UDP transport is perfect for that (and used a lot in real 
life).
TCP however decides on its own how to transport a data stream. That means there are no message boundaries preserved in 
that transport.
This lack of message boundary is what is likely causing mayhem in your TCP based solution.
What to do? Well, even though we know now that TCP as a transport isn’t suitable for message based transport, you can 
always put a protocol on top of TCP to help and maintain message boundaries for the application to work with. Or the 
application protocol already has enough message boundary information and is it just the application code which has to 
handle the fact that it may get partial messages from the TCP transport.
Another thing is that TCP might block when a packet is lost. This causes timing problems for your video as well. That 
is why media is usually transmitted over UDP.
There’s lots more to say about this subject, but there’s much better course material out there explaining all this.

Thanks,
Jaap



On 7 Feb 2017, at 06:38, samira afzal <afzal.samira () gmail com<mailto:afzal.samira () gmail com>> wrote:

Hi everyone,
I don't know that i can ask it in this forum or not. but i couldn't receive any reply in 
http://stackoverflow.com/questions/42031219/rst-in-video-streaming-over-tcp-socket.
I hope your help.

up vote
down votefavorite<http://stackoverflow.com/questions/42031219/rst-in-video-streaming-over-tcp-socket>

I have an application for video streaming over UDP and it works completely success. I changed the socket to TCP. When 
it is running after a few packets transferring, receiver sends RST and it stops working. (The packet with a large 
length is also strange which transferred from sender to receiver while MTU is 1400 - what is this packet?)
[enter image description here]<https://i.stack.imgur.com/eGXGX.png>
I checked receiver and sender log. The last packet that was received by receiver has a large and strange sequence 
number (dump packet). It makes an error and then application stops. Sender is not sending such a packet. Where is this 
packet come from? Is it transport layer that makes it?
[enter image description here]<https://i.stack.imgur.com/5XN91.png>
When I added a sleep time (0.1 second) to the sender after each packet sending. The program works without any strange 
large length packets in Wireshark or strange sequence number But this is not a reasonable solution for video. What is 
your suggestion now? what could be the problem? How could analyze this network? How could solve it?

Thanks in advance


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe