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
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 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 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 7 years ago.
Improve this question
Unsure if this is the correct place for this kind of question (Server Fault is for administrators) but I'm looking for examples of (networking) protocols and standards that leverage the huge IPv6 address space towards some specific benefits.
Reason is I'm writing a paper about something that does this and I'm searching for stuff to compare it to, but I'm coming up empty even though I'm sure some have to do so.
Probably not completely on topic here, but I'm going to answer it anyway because it might help software developers to learn what possibilities there are when developing for IPv6.
Because most protocols and applications still want to be compatible with IPv4 there aren't that many protocols that use this wonderful feature of IPv6. Most of the ones that do are IPv6-only by nature.
The first one is of course IPv6 Stateless Address Autoconfiguration often abbreviated to SLAAC. Having so many addresses available makes self-assignment of addresses so much easier.
Building on that is SEcure Neighbor Discovery (SEND) with Cryptographically Generated Addresses (CGA) which uses public key cryptography and derives the last 64 bits of the IPv6 address from the fingerprint of that public key. Because the node can create a signature with the private key that matches the public key it can prove that it is the legitimate holder of that IPv6 address. Unfortunately there are no implementations for the most common operating systems so this feature is largely unused.
And another one is the IPv6 Battleships game. It uses IPv6 addresses to encode the coordinates in the game and by sending a ping the opponent can determine of there is a ship at a certain location (address) or not. The game was written in a competition on World IPv6 Day at the IPv6 event in The Netherlands.
It has significant advantages for large Cloud deployments. For instance, Faceebook has reported 90% of its internal traffic is IPv6 (https://t.co/PPHBkUPTdt) because this way is similar to private IPv4 but serves better to v6 native customers (in the same report they claim v6 mobiles surf 30%-40% quicker than v4 ones). Also Openstack has finally added almost-full v6 support for Juno version.
Additionally, the IoT field (when it is really IoT, I mean IP devices) is an excellent field of application. Normally, devices will use either IPv6 (when powerful enough) or 6LowPAN (an reduced IPv6 for sensor networks and supported well in OS like TinyOS, ContikiOS, mbedOS, etc).
It might be also useful for WebRTC-like applications as long as IPv6 peers would normally connect better (firewalls vs NATs seem to behave or be more easily configured).
However, with the massive deployment that has started in 2015 (in USA 17% of all traffic to Google is v6, Germany traffic to Google is 14%, all Internet traffic to Google is 7% IPv6 today) any Internet product of service has to migrate or will lose competitiveness soon.
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.
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 9 years ago.
Improve this question
I wanted to know if there is any way to send larger files than 65,536 bytes by using IPv4
You shouldn't be using raw IP.
There's a reason an implementation of TCP/IP is typically called a "stack". Communication is typically done by layering protocols on top of each other. Each layer takes the layer below it, and either abstracts away some aspect of the lower-level protocol or adds useful functionality.
A web server, for example, ends up using several layers of protocols:
Ethernet, WiFi, or other such protocols, which provides the physical (or radio) connection and signaling rules that enable machines to talk to each other at all.
IP, which adds the concept of routing and globally available addresses.
TCP, which
adds a concept of "ports", which allows several apps to use the same IP address at the same time without stepping on each other's toes;
abstracts the discrete packets of IP into a full-duplex, arbitrary-length stream of bytes; and
adds detection and correction of errors and lost/duplicate data.
SSL and/or TLS (sometimes), which adds semi-transparent encryption (once established);
HTTP, which adds structure to the stream by organizing its contents into messages (requests and responses) that may (and almost always do) include metadata about how the body of the message should be interpreted.
At the API level, you will almost always start with a transport-layer protocol like TCP, UDP, or sometimes SCTP. It's rare for the OS to even allow you to communicate directly via IP, for security reasons.
So in order to transfer a file, you'd need to
Establish a TCP "connection" to the other machine, which will typically be running a service on some known port. (For HTTP, that's typically 80.) This in itself removes any limit IP imposes on data size.
Set up SSL or TLS, if the other end requires it. You probably shouldn't bother with them yet, though. It's an optional, and non-trivial, addition, and most servers provide some way to communicate without it.
Use the application-layer protocol that the other end understands in order to send a request to store a file (and, of course, the file contents).
There is not relationship between the version of IP you are using and the size of file you can transmit Do your homework, please.
That depends what you mean by "files". Large files are sent over the network every day, and it's still like 99% IPv4, so I suppose most correct answer would be "yes". You might want to read on transport protocols, most prominent of which is TCP.
I recently checked out the book "UNIX Network Programming, Vol. 1" by Richards Stevens and I found that there is a third transport layer standard besides TCP and UDP: SCTP.
Summary: SCTP is a transport-level protocol that is message-driven like UDP, but reliable like TCP. Here is a short introduction from IBM DeveloperWorks.
Honestly, I have never heard of SCTP before. I can't remember reading about it in any networking books or hearing about it in classes I had taken. Reading other stackoverflow questions that mentions SCTP suggests that I'm not alone with this lack of knowledge.
Why is SCTP so unknown? Why is it not much used?
Indeed, SCTP is used mostly in the telecom area. Traditionally, telecom switches use SS7 (Signaling System No. 7) to interconnect different entities in the telecom network. For example - the telecom provider's subscriber data base(HLR), with a switch (MSC), the subscriber is connected too (MSC).
The telecom area is moving to higher speeds and more reachable environment. One of these changes is to replace SS7 protocol by some more elegant, fast and flexible IP-based protocol.
The telecom area is very conservative. The SS7 network has been used here for decades. It is very a reliable and closed network. This means a regular user has no access to it.
The IP network, in contrast, is open and not reliable, and telecoms will not convert to it if it won't handle at least the load that SS7 handles. This is why SCTP was developed. It tries:
to mimic all advantages of the SS7 network accumulated over the decades.
to create a connection-oriented protocol better than TCP in speed, security, and redundancy
The latest releases of Linux already have SCTP support.
We have been deploying SCTP in several applications now, and encountered significant problem with SCTP support in various home routers. They simply don't handle SCTP correctly. I believe this is primarily a performance issue (the SCTP protocol specification require checksums for the whole packets to be recalculated and not just for headers).
Like many other promising protocols SCTP is sadly dead in the water until D-link and Netgear fixes their broken NAT boxes.
SCTP is not very much known and not used/deployed a lot because:
Widespread: Not widely integrated in TCP/IP stacks (in 2013: still missing natively in latest Mac OSX and Windows. 2020 update: still not in Windows nor Mac OS X)
Libraries: Few high level bindings in easy to use languages (Disclaimer: i'm maintainer of pysctp, SCTP easy stack support for Python)
NAT: Doesn't cross NAT very well/at all (less than 1% internet home & enterprise routers do NAT on SCTP).
Popularity: No general public app use it
Programming paradigm: it changed a bit: it's still a socket, but you can connect many hosts to many hosts (multihoming), datagram is ordered and reliable, erc...
Complexity: SCTP stack is complex to implement (due to above)
Competition: Multipath TCP is coming and should address multihoming needs / capabilities so people refrain from implementing SCTP if possible, waiting for MTCP
Niche: Needs SCTP fills are very peculiar (ordered reliable datagrams, multistream) and not needed by much applications
Security: SCTP evades security controls (some firewalls, most IDSes, all DLPs, does not appear on netstat except CentOS/Redhat/Fedora...)
Audit-ability: Something like 3 companies in the world routinely do audits of SCTP security (Disclaimer: I work in one of them)
Learning curve: Not much toolchain to play with SCTP (check the excellent withsctp that combines nicely with netcat or use socat, 2020 edit: nmap supports it for a few years now )
Under the hood: Used mostly in telecom and everytime you send SMS, start surfing the net on your mobile or make phone calls, you're often triggering messages that flow over SCTP (SIGTRAN/SS7 with GSM/UMTS, Diameter with LTE/IMS/RCS, S1AP/X2AP with LTE), so you actually use it a lot but you never know about it ;-) 2020 edit: it's being removed from the core 5G network (no more Diameter, HTTP/2 instead) and will be only used in the 5G radio access network between antennas and core.
SCTP requires more design within the application to get the best use of it. There are more options than TCP, the Sockets-like API came later, and it is young. However I think most people that take the time to understand it (and who know the shortcomings of TCP) appreciate it -- it is a well designed protocol that builds on our ~30 years of knowledge of TCP and UDP.
One of the aspects that requires some thought is that of streams. Streams provide (usually, I think you can turn it off) an order guarantee within them (much like a TCP connection) but there can be multiple streams per SCTP connection. If your application's data can be sent over multiple streams then you avoid head-of-line blocking where the receiver starves due to one mislaid packet. Effectively different conversations can be had over the same connection without impacting each other.
Another useful addition is that of multi-homing support -- one connection can be across multiple interfaces on both ends and it copes with failures. You can emulate this in TCP, but at the application layer.
Proper link heartbeating, which is the first thing any application using TCP for non-transient connections implements, is there for free.
My personal summary of SCTP is that it doesn't do anything you couldn't do another way (in TCP or UDP) with substantial application support. The thing it provides is the ability to not have to implement that code (badly) yourself.
FYI, SCTP is mandated as supported for Diameter (cf RADIUS next gen). see RFC 3588
Diameter clients MUST support either TCP or SCTP, while agents and
servers MUST support both. Future versions of this specification MAY
mandate that clients support SCTP.
p1. SCTP mapped directly over IPv4 requires support in NAT gateways, which has never been widely deployed anywhere, and without it the typical NAT gateway will only permit one private host per public address to be using SCTP at a time.
p2. SCTP mapped over UDP/IPv4 allows more private hosts per public address, but UDP mappings in IPv4/NAT gateways are notoriously tricky to establish and keep maintained, due to the fact that UDP is a connectionless transport without any explicit state for a NAT to track.
p3. SCTP mapped directly over IPv6 requires... well... IPv6. Have you tried to deploy IPv6? If so, have you tried to buy an IPv6 firewall? Does it support SCTP? How about a load balancer? A SSL accelerator?
p4. Finally, a lot of the Internet is pretty much constrained to what can fit through TCP port 80 and port 443, so SCTP of any flavor tends to lose there. Hence, you see efforts like the MPTCP working group in IETF.
Many of us will be using SCTP soon, since it's used by WebRTC datachannels to create a TCP-like reliable layer on top of UDP -- SCTP over DTLS over UDP: https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel-13#section-6
Reading the SCTP Wikipedia page I'd say that the main reason is that SCTP is a very young protocol (proposed in 2000) that is currently unsupported by the mainstream OSs (Windows, OS X, Linux).
If "very young" seems inappropriate to you, think about IPV6: "in December 2008, despite marking its 10th anniversary as a Standards Track protocol, IPv6 was only in its infancy in terms of general worldwide deployment."
SCTP is used extensively in the 4G LTE network where Diameter is used for AAA.
It might not be well known, but it's not unused. Quite recently there was a draft published at the IETF about Using SCTP as a Transport Layer Protocol for HTTP.
In reference to all of the comments about commercial routers being broken or lacking SCTP support, the issue is that SCTP with NAT is still in draft form with the IETF. So there is no RFC specification for them to implement it.
https://datatracker.ietf.org/doc/html/draft-ietf-behave-sctpnat-09
Sctp is born too late, and for many situation TCP is enough.
Also, as I know most of its usage is on telecommunication area.