Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
So i started to learn tcp/ip protocol stack. But in all sources tcp protocol is described too blurry. The main think i want to know how actually tcp protocol programly implemented. how applyed protocols communicate with tcp protocol. what is interface of this communication. For now i think that applied protocols are implemented directly in applied program: lets say browser implement HTTP protocol and this protocol communicate with centralized implementation of tcp protocol which is implemented in OS. IS it correct i have lack of sources from which i can learn this.please recomend me something to read.
Note: while your question is leaning towards being broad, I am answering it since I think that it is a good introductory question.
TCP is a layer-4 (or transports layer) protocol. Network applications sit on top of it (and other layer-4 protocols like UDP). Applications can interface with Layer-4 protocols via a socket interface (http://linux.die.net/man/7/socket). HTTP is also an application that runs on top of TCP and would be using the socket interface. Besides HTTP, there many other famous applications that run on top of TCP, like Telnet, BGP, etc.
One of the best book to understand basics of TCP and options would be "TCP/IP Illustrated, Vol. 1: The Protocols" by Richard Stevens. It talks about how TCP works and various options. Here is a link: http://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469
Once you have read that, you probably should read the RFC itself: http://www.ietf.org/rfc/rfc793.txt
For details of implementation, you can read its second volume: "TCP/IP Illustrated: The Implementation, Vol. 2". Here is a link: http://www.amazon.com/TCP-IP-Illustrated-Implementation-Vol/dp/020163354X . While this books talks about BSD implementation -- it should still help you understand the basic mechanics of how TCP implementation works.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
Obviously TCP/UDP are supported in Windows but are there any other transport protocols? I know that SCTP and DCCP exist but cant seem to find any reference to them with regards to their support in Windows OSes and only managed to find third party drivers but none seem to be past Windows 7. Is the lack of support due to lack of use or another reason?
mostly used traport layer network protocols are tcp and udp yes
TCP (1981), UDP (1980)
Stream Control Transmission Protocol aka SCTP (2007) combines TCP and UDP, reliable as tcp, uses datagrams like in UDP and supports multiple parallel streams of chunks
SCTP RFC4960
Datagram Congestion Control Protocol aka DCCP (2006) provides bidirectional unicast connections of congestion-controlled unreliable datagrams.
DCCP RFC4340
Edit: the following is the conclusion of a paper written while back
Adding multihoming and mobility support to Internet transport
protocols changes the environment in which transport-layer security
mechanisms operate. This may cause non-cryptographic security
mechanisms, such as TCP sequence numbers and SCTP verification tags,
to break. The attacker may be able to spoof data and signaling
messages and hijack connections. Dynamic multi-addressing also gives
raise to new types of attacks such as address squatting, redirection
of data from a server to the target of a bombing attack, and
connection forwarding. In this paper, we describe a number of such
attacks against SCTP and suggest low-cost changes to the protocol
specification and implementations. Several SCTP implementations were
found to be vulnerable to all or most of the attacks described in this
paper. Table 1 summarizes the main protocol weaknesses, attacks and
solutions and how they relate to each other. (Some attacks depend on
multiple vulnerabilities, which is indicated by multiple crosses in
the column. We have also marked the changes that should be made
immediately to the implementations.) The lessons from our security
analysis apply to other transport protocols and to practically any
multihoming or mobility solution that uses end-to-end signaling.
you can find the paper here
I will not claim a prize, but I would like to share my experience in the field of network packages. I recently started learning the Scapy tool written in Python. With the help of this tool, I was able to more clearly and clearly understand the work of network packets and, moreover, understand how they work and are supported. This tool helped me a lot. Maybe he will give you some answers to your questions.
>>> ls(SCTP)
sport : ShortField = (None)
dport : ShortField = (None)
tag : XIntField = (None)
chksum : XIntField = (None)
>>> a=SCTP()
>>> a.show()
###[ SCTP ]###
sport= None
dport= None
tag= None
chksum= None
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
Improve this question
I deal with design of peer to peer communication between mobile unit and user phone. Mobile unit is targeted into cars, so it is possible that it could be connected to many various ISPs. It can be also expected that the clients will be often disconnects. I need to find best solution in NAT traversal techniques, which is applicable in conditions of mobile network, which are little different than the usual networks as WiFi. I search for often used techniques and found a many different practices, such as TCP or UDP Hole Punching, NUTSS, NATBLASTER, NatTrav or official protocols such as STUN or ICE.
Could anyone advise me tried and proven technique under similar conditions?
Thank you very much
To achieve peer to peer(P2P) or relay connectivity you need to implement a protocol called ICE. This protocol allows you the ability of 100% NAT traversal. This is the best solution currently exist. You need to have STUN/TURN server as well.
With even the best solution ICE, you will not get 100% P2P connectivity between peers. Some connection will be established through a relay server called TURN. This depends on the type of NATs the peers are behind.
TCP or UDP Hole Punching is a special technique to allow some connection which normally would have been relay to be P2P. There are other techniques like that but those come after you implement ICE and have STUN/TURN server.
There are lots of open source STUN/TURN server and some companies provides solution for ICE. Some companies provide the whole NAT traversal solution providing ICE implementation and STUN/TURN server support.
Other than TURN, you can also try UDP multi-hole punching, although it may be "too unreliable to be worth the hassle"
https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Firstly, thank you for taking the time out to read this post.
I'm looking to develope a TCP/IP enabled device using the Microchip PIC18 or PIC32 family of embedded microcontrollers with Microchip's TCP/IP Stack. However, my knowledge of networking is pretty basic at the moment, thus the reason for this post.
Can anyone recommend the best protocol to use for my TPC/IP embedded device so that it can communicate with a server in a data centre? My intention is to have the embedded device located at a remote location somewhere over the internet, where the server can communicate with the device and download data such as thermometer probe readings to be stored in a database. I would also like the ability for the server in the data centre to be able to reconfigure settings and variables on the remote device should I need to.
My research on protocols so far has lead me to the following options:
SNMP v3 (version 3 due to encryption and authentication)
UDP (though I read this can be unreliable but is fast)
TCP (I'm not too clued up on this yet)
Can anyone offer me advice on the best route to go down? I'm not expecting a detailed answer from you, but I would really like an idea of what topics/protocols to look into and research.
My intent is to deploy many of these embedded devices over the internet where they all send their data back to the server.
I assume that the remote embedded device will have to connect to the server rather than vice versa as the server will have a static IP address or DNS name, whereas the remote device addresses will be unknown.
Any advice on this would be greatly appreciate. Please don't hesitate to ask if I've missed out any key information in this post.
Many thanks.
Rob
* UPDATE *
It was pointed out that I'm probably misusing the term Web Server, so I've amended my post to mention Server in a Data Centre instead. Thank you for pointing this out to me.
If the target is a Web server you don't have any choice. You have to use HTTP, which runs over TCP.
Or else you are misusing the term 'Web server'.
In many ways this depends on your specific requirements. TCP/IP is able to provide quite reliable connections because it provides a means to determine if the client is connected, when they connected and when they disconnected. UDP is connectionless, so the server opens a port and listens for data, but has no automatic connection management, so clients need to explicitly 'tell' the server when they have arrived or are going (this also means you will need to make your own timeout facility).
Also, if you have very limited memory/processing resources, it is worth bearing in mind that UDP is a less 'costly' protocol as it avoids a lot of the overheads TCP incurs due to its inbuilt connection management.
While these are all protocols, they really just handle the connections themselves. You will probably still need to create your own protocol for the management of the data itself. For instance, when you send data over either TCP or UDP, the bytes you send may not all arrive to the server at the same time. This means you need a way of validating each packet you receive to ensure you have it all. This is often achieved with a combination of a checksum and a byte representing the total size of the data sent.
You might also consider mqtt (http://mqtt.org). It is a lightweight messaging protocol. For encoding your messages, you might consider protobuf (https://code.google.com/p/protobuf/)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 8 years ago.
Improve this question
If user datagrams are not numbered(in UDP) then how the received data is ordered. Consider small applications involving small data transfers.
As a transport-layer protocol, UDP does not guarantee in-order delivery. For that, you would need to use a stream-based (transport-layer) protocol like TCP (or SCTP). UDP is a lightweight protocol by design and so does not offer in-order delivery. If the application wishes to have an in-order delivery, it would have to handle on its own.
The motivation behind a simpler design is true for other transport-layer properties as well, like retransmission, estimation of sending rate, and flow-control. UDP does not do any of these. Its simplicity leads to lower delay. Hence, as compared to TCP, UDP is more attractive for delay-sensitive applications like Audio/Video.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Let's say somebody invented a new protocol I would put on top of IP. Would two computers from the other ends of the world be able to communicate with it, i.e. would routers forward the frames that aren't standard TCP/UDP/ICMP?
Yes, if it is build on top of IP then it would be routable over the internet. The IP protocol defines the header and payload. The header is used for routing. So you would be able to send custom IP-based protocol data from one computer to another over the internet.
However, both computers will need custom drivers to send, receive and understand the data.
I'm not sure why you'd bother though. If you're sending custom data, you're much better off writing an application level protocol on top of tcp or udp and take advantage of the networking layer built into all computers and operating systems already. It'll be easier to write, maintain, and debug.