when connecting two network interface adapters directly (using just an ethernet cable, with no networking equipment whatsoever in between), is it correct to assume that all UDP packets sent from one NIC will be received by the other in the same ordering? (I know packet loss will still be a problem, but for this particular question I would like to focus on ordering).
Thanks!
You can't assume anything with UDP: delivery, non-duplication, sequence, ... The only exception is that if you do receive a datagram it is intact.
Theoretically no as UDP implementation in OSI level is at layer 4 i.e. transport layer and the underlying layer of UDP might decide to sequence the packets different way. Remember, the network layer (layer 3) is responsible for fragmentation and reassembly of data.
However, practically, depending on the implementation, it is quite safe to assume that the sequence will remain the same.
Related
we know that transport layer protocols like tcp control the flow and take care of the reliability by slide window and acknowledges ...etc. the data link layer with LLC sub layer has the same functionality for reliable connections also. the first question : is this means that both layers do the same functions twice? or when we use tcp in transport layer there is no need for LLC reliability functions ?how is it working ?
the second question: since IP layer is unreliable when it sends and receives packets, is this means that routers witch are layer 3 devices with no tcp protocol above it depends on LLC sub layer to takes care about the reliability "I mean between two routers" ?
I dont think you need other reliability, in words of disruption, both IP and Physical protocls (such as Ethernet) have CRC and Checksum in order to prevent disruption, but in terms of packet loss, TCP is what's called a stream protocol - it transfers you a stream of bytes, Sequence / Acknowledgment number server that purpose and help you keep track of bytes sent/read by client, if some weird "jump" in those numbers would be made, an ACK message wont be sent by receiving side, and protocol's sender would re-send lost packets hence I don't think that you need some reliability in terms of packet loss as TCP covers that for all downwards layers.... not sure I fully understood your question though, thats when we use TCP
about using pure IP and physical layer protocols, I honestly have no idea how to prevent packet-loss yet disruption is prevented by as mentioned earlier - checksums
Recently I dug a bit deeper into the matter of network protocols and the OSI model, when noticed, that incoming TCP datagrams (correct me if this is the wrong term) are splitted into several parts, when they exceed a certain size - in this case it's propably my router's MTU. I captured those datagrams using SharpPcap in order to extract some information i am looking for, if you are wondering where I got this information from.
Anyway I was wondering if the reassembly of fragmented packets shouldn't be task of the IP layer, since it definitely provides information to accomplish this (id, fragmentation flags, fragment offset). Furthermore I read, that the TCP layer is to be interpreted as a stream-based protocol. But this actually implies, that it's up to the TCP layer to care about filling the application's buffer the right way, so that the initial piece of information is reconstructed and may be flushed "up" all further layers.
Before I made this observation I actually thought, that the TCP layer should care about reassembling those datagrams, but none of the mentioned layers does...
This leads to the following question(s):
Why are the TCP datagrams I receive not reassembled and what layer SHOULD actually take care about this?
The ip layer handles fragmentation and reassembly, http://en.wikipedia.org/wiki/IP_fragmentation.
When you use a tool like SharpPcap that uses winpcap/airpcap/libpcap, you are receiving the raw datagrams from the device you are capturing on. For many adapters this is an ethernet datagram that then contains an ip frame etc.
This is in contrast to data received after processing by the networking stack, where the reassembly is performed.
So, its expected that you won't get reassembled datagrams from SharpPcap (or many other capture libraries) because the data is being captured at the adapter level, not inside of our as an output of the networking stack that is performing reassembly.
You can perform the reassembly after capture either yourself or using a library that provides this functionality. You could also add such a component to Packet.Net (the packet processing library that SharpPcap is using) to provide this reassembly.
The UDP protocol does not guarantee packets being received sequentially, but you could just use part of the datagram for a sequence number.
Compared to the guarantee of TCP, is the above solution for UDP equivalent?
Basically, I've been reading everywhere that UDP does not provide sequential receiving, but this seems like such an obvious fix that I was wondering if it is truly an adequate fix.
The only 'disadvantage' is that you lose a few bytes of data space.
However, by itself, it isn't a solution. You have to add ACK messages into your protocol so that the sender knows what you have and haven't received; you have to buffer sent datagrams at the sender until they are ACK'd in case you have to retransmit then; and you have to either buffer out of sequence datagrams or throw them away so you can reconstruct the sequence correctly. Having come this far, it would also be sensible for the sender to implement some form of flow control or pacing if it notices a lot of retransmission being required.
This is a good way towards implementing TCP. Most people give up at this point and use TCP.
Using UDP in that fashion makes the application need to handle packet reconstruction and sequencing. That creates overhead in the application layer of the network. TCP is probably more efficient at handling that in the transport layer.
As well, UDP does not provide a mechanism for resending lost packets. When your application notices that the sequence numbers skipped one, there is some ambiguity in the meaning. Is there a lost packet or a delay packet? Your application would need to be able to detect that, and be able to request that the packet be sent again via a packet number reference.
In other words, there is a reason for the overhead of TCP when in-order guaranteed delivery is required.
https://en.wikipedia.org/wiki/User_Datagram_Protocol
It sounds like you want a form of partial reliability, inbetween TCP and UDP.
An option is to use SCTP-over-UDP (SCTP, portable userspace & kernel source). SCTP lets you set in-order for unreliable UDP-like streams , and also for partially-reliable streams (limited time or number of re-transmits)
.
Of course you could implement the missing features from TCP in UDP but that would destroy the purpose of UDP. The point is that the TCP implementation in your network stack peforms all the neccessary operations for you. (Involving packet reassembling and packet loss).
If you need TCP than you should use it. UDP is designed for packets where you don't care if they got lost (like VOIP, Gameserver, etc.).
According to my knowledge if an internet application has to be designed, we should use either a connection-oriented service or connection-less service, but not both.
Internet's connection oriented service is TCP and connection-less service is UDP, and both resides in the transport layer of Internet Protocol stack.
Internet's only network layer is IP, which is a connection-less service. So it means whatever application we design it eventually uses IP to transmit the packets.
Connection-oriented services use the same path to transmit all the packets, and connection-less does not.
Therefore my problem is
if a connection oriented application has been designed, it should transmit the packets using the same path. But IP breaks that rule by using different routes.So how do both TCP and IP work together in this sense? It totally confuses me.
You, my friend, are confusing the functionality of two different layers.
TCP is connection oriented in the sense that there's a connection establishment, between the two ends where they may negotiate different things like congestion-control mechanism among other things.
The transport layer protocols' general purpose is to provide process-to-process delivery meaning that it doesn't know anything about routes; how your packets reach the end system is beyond their scope, they're only concerned with how packets are being transmitted between the two end PROCESSES.
IP, on the other hand, the Network layer protocol for the Internet, is concerned with data-delivery between end-systems yet it's connection-less, it maintains no connection so each packet is handled independently of the other packets.
Leaving your system, each router will choose the path that it sees fit for EACH packet, and this path may change depending on availability/congestion.
How does that answer your question?
TCP will make sure packets reach the other process, it won't care HOW they got there.
IP, on the other hand, will not care if they reach the other end at all, it'll simply forward each different packet according to what it sees most fit for a particular packet.
Note:
Let's assume that IP was connection-oriented, would that mean packets would follow the same-path?
Not necessarily, it depends on what the word 'connection' at this layer means, if it means negotiating certain options related to security, for instance, you may still have all your packets being forwarded through different routes over the Internet.
EDIT:
Not to confuse you though, most connection-oriented services at the network-layer and below mean that the connection, when established, also establishes a virtual-path that all 'packets' must follow, for further information read about:
Virtual circuit and frame-relay networks
This link answers your question pretty well http://www.tcpipguide.com/free/t_ConnectionOrientedandConnectionlessProtocols-3.htm
Some people consider this (TCP) to be like a “simulation” of circuit-switching at higher network layers; this is perhaps a bit of a dubious analogy. Even though a TCP connection can be used to send data back and forth between devices, all that data is indeed still being sent as packets; there is no real circuit between the devices. This means that TCP must deal with all the potential pitfalls of packet-switched communication, such as the potential for data loss or receipt of data pieces in the incorrect order.
The TCP protocol deals with the problem of IP packets arriving out of order or being lost, to give you the feeling they arrive through a single FIFO channel. Yes, TCP is smart enough to do that, there's no need for a dedicated underlying channel.
The TCP protocal is implemented by the sending/receiving machines, once the packets leave the sending machine, the routers they travel along know nothing about TCP, they just use IP to get the packets from the source the to destination. Then, it is the destination machines job to, using TCP, make sure that all the packets arrive and that they arrive in the correct order. The internet itself doesn't know anything about TCP, it's just a layer (often software) that gives connection to a connectionless medium (the internet).
So onces a packet leaves a destination, it can go along any path (mostly) as long as it gets to the desintation, regardless of the higher level protocol (such as TCP or UDP).
I mean, it's a bit more complicated then that, but as far as I can remember that's the general Idea.
Refer my short points properly,
1) Connection oriented means ==> reserving resources(buffer,cpu,bandwidth etc.)..but "Where??".(where resources are reserved?? This where is reason of your confusion, so following is ans.).
2) Connection oriented at Transport Layer means ==> Reserving the resources at Both End processes/Ports.(Since TCP is a transport layer,then its responsibility is to reserve the resources at both end processes only,irrespective of whats happening in the intermediate path.)
3) Connection oriented at Network Layer means ==> Reserving the resources at Network Layers.(Now In the whole journey of a packet from source to destination, Network layer is found at all intermediate routers too(but not transport layer). Hence if any protocol at Network layer is connection oriented then,its responsibility is to reserve resources at all intermediate routeres too i.e. all packets will have to follow same intermediate path, But IP is connection less hence,intermediate resources will not be reserved. i.e journey of a packets may follow different paths etc.)
#CONCLUSION:==> Intermediate path is decided by Network Layer, hence if IP then paths may be different.(IP may contain TCP),But TCP is responsible for Resource reservation at both End processes ,irrespective of Intermediate path of packet.
router works on three layers only (physical , data link and Network layers) , so routers will take decision depending only on the info. of network layer (IP protocol ) hence there is no information available about its TCP or UDP at the router
I am trying to simulate a wifi video transmission and for that I created a connection using a socket between 2 devices, however I then started to doubt whether this is required or if I was supposed to create a UDP connection.
I think I'm just confused on terms here and I've Googled and I found out that Wifi can has TCP or UDP my question would then be would a Wifi Transmission over TCP be as reliable for a simulation as one with UDP?
I'd suggest you to read Difference between TCP and UDP?.
For streaming like video transmission you would generally want to use UDP. If a packet cannot reach the server in time, it'd better be discarded than pausing the whole transmission in order to wait for one tiny missing packet that just contains the other person blinking.
But obviously it's up to you and how you implement your software.
You may need to read up a bit on the TCP/IP protocol. TCP and UDP are just types of packets/datagrams. The main difference is that TCP packets include extra protocol information, whereas UDP are simpler packets with just a destination, the data itself, and a checksum.
The upshot is that the sender of a UDP packet has no way of knowing whether or not the packet was received at the other end. Often this doesn't matter - because it may be handled in other ways by higher layers in the software, or can be simply lost and ignored without any negative consequences. So UDP can be a more efficient use of the bandwidth, in some scenarios - because there is less protocol information being exchanged, and therefore more actual data. Plus TCP is more complicated because you have to handle the protocol stuff.
So when you create your system, you have a choice - either TCP or UDP packets, depending on what you are trying to achieve and how you want to go about it. But both packet types are really all part of the "tcp/ip" protocol stack, and have similarities.