Re: RST In video streaming over TCP socket?

[samira afzal <afzal.samira () gmail com>]

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 () ericsson com>
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 () 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> 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?)
>
> [image: 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?
>
> [image: 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
___________________________________________________________________________
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