Wireshark · Wireshark-users: Re: [Wireshark-users] RST In video streaming over TCP socket?

[samira afzal <afzal.samira@xxxxxxxxx>]

Thanks for your guides and helps Jaap and Anders.

Jaap,

a) What could be " protocol on top of TCP"? could you please tel me some examples? could MPEG-Dash be an instance?  The application that i am using is MMT protocol. 

 b) In the sender side, MMT checks the  length of each sample and it has to be at most equal to MTU ( which sets with user) if it is more than that value, then it divides to several fragments each one at most equal to MTU size . Is it different of what you tell about message boundary at sender side? 

At receiver, MMT is receiving data with size of recv buffer (in socket programming) and i believe it is not  "message boundary information" that you are talking about.

c) What do you suggest to me? changing MMT and adding this boundary? or adding another protocol beside MMT and TCP?

Thanks a lot for your time and guides.

On Tue, Feb 7, 2017 at 6:27 AM, Anders Broman <anders.broman@xxxxxxxxxxxx> wrote:

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@xxxxxxxxxxxxx] On Behalf Of Jaap Keuter
Sent: den 7 februari 2017 07:51
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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

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?) 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? 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe