There is the IP - Internet Protocol. It allows us to address some computer in global network - Internet.
There is also a port - endpoint destination on that addressed computer. Someone can establish such an endpoint through socket - a so-named handful of operating system calls (API) and combination of IP address and port. It can be done using one of two "transport" protocols - either TCP or UDP. TCP provides a guarantee of delivery, UDP doesn't. In both cases someone given with a stream of bytes which he/she can read and write back. Such a stream has no meaning as it's own - someone can and should interpret it as he/she likes.
Socket API is well established and straightforward.
There is major wave nowadays: many global companies tend to implement it's own, "brand new" protocols. In fact, seems like many of them just discard using TCP reliable delivery and implement it's own using UDP (what is the reason to fight TCP reliability, though?).
Is there a way to implement a brand new "transport" protocol which will coexists with TCP and UDP? Will it be accessible through socket APIs? If not, then how?
Are there any practical reasons to do this?
Related
What is the difference between a "tcp/socket" and "tcp/ip" connexion?
When you say that you use "tcp/ip", do you necessarily use a "tcp/socket"?
Thanks!
A socket is a general communication means provided by your
operating system.
There are many kinds of them, for very distinct purposes
(not only networking).
I guess that when you think about tcp/socket, you mean a
socket dedicated to the TCP protocol.
TCP/IP can be seen as two different things, depending on the context.
It can be the TCP/IP network stack as a whole: not only the TCP and IP
specific protocols but the set of protocols (and implementations) we
find around these.
Of course, the other way to see TCP/IP is to consider only the TCP
transport protocol relying on the IP network protocol.
The various operating systems implement many protocols
in the TCP/IP stack.
To use them, a programmer asks his/her operating system
a specific resource: a socket.
It's difficult to say more with few words.
Some books or online documentation could help go further.
I think you missing something in the question. Anyway in short...
TCP/IP is basically name given to protocol we (networking devices) follow it forms the fundamental of todays internet. It involves agreement between two devices how the want ro communicate eg. Which segment of a frame has what information as in the end its all just 10...
There are 5 layers (some argue 4) in this model one layer is Network Layer right at the middle of all and it generally uses IPv4.And just above this is our Transport Layer which may use TCP or UDP as protocol depending on service you want. So thats the summary of TCP/ IP as the most used set of protocols of all.
When connecting to a remote server your browser needs to know what kind of service he is about to get from that server eg. a video mail or file transfer or just a http page. Thats when a TCP/Socket comes into picture where there is a port no assigned for every service. Eg port 443 is for https and so on. All you need to do is open a socket connection over that port number on that machine
Remember if a particular port of a server is not in LISTEN mode you cannot connect to that application via that port
Eg. If a server serves its webpage it might not allow you to connect its port responsible for FTP.
Hi guys I'm new to understanding protocols used over the web and need some help in understanding the basics of websockets,TCP/IP and HTTP.
My understanding of the relation between TCP/IP and HTTP is that IP is required to connect all networks. TCP is a mechanism that allows us to transfer data safely and HTTP, which utilizes TCP to transfer its data, is a specific protocol used by Web servers and clients.
Does this mean you can't send a HTTP request without TCP?
Websockets communicate using TCP layer and a connection between client and server is established through HTTP which is known as the handshake process.
Does websockets have its own protocol? How can you send a http request(hand shake process) to establish TCP/IP when you need TCP to carry out an HTTP request. I know I am missing something really important here and would be great to get my understanding of these protocols sharpened!
Firstly, IP is not necessarily required to connect all networks. However, it is the most widely used and adopted today (For now that is). Old network protocols such as Appletalk, IPX, and DECNet are all legacy network protocols that are not much used anymore, however they are still around to an extent. Don't forget IPv6 is out there as well, in some places, and can ride over IPv4 networks if your configuration is done properly.
When you say TCP being "safe", I would give it another word, and that would be intelligent. TCP is a transport protocol, and is the header that comes directly after the IPv4 header. TCP is primarily used for flow control and has become very efficient at error recovery in case a part of a packet or packets has been last when transferring/receiving. While this is great for some transactions, the error control requires an additional amount of overhead in the packet. Some applications, let's say VoIP for example, is very sensitive to delay, jitter (Variation in delay) and congestion. This is why it uses UDP.
Like TCP, UDP is a transport protocol, however there is no flow control. Think of it this way: When sending packets over TCP, it's like asking the other end if they received your message. If they did, they will acknowledge it. If not, you now have to determine how you will resend this information. UDP has none of this. You send your message to the other side, and hope it gets there.
Now if you want to talk about "safe" protocols, this is usually done at either the network layer (IPSec) or the application layer (SSL). Safe typically means secured.
A usual TCP three-way handshake looks like this:
Whoever sends the SYN is the client. Whoever receives that initial SYN is the server.
Client sends SYN --> Server
Now, if the server is listening, and/or there's not a firewall blocking the service (Which in that case you'd receive a TCP frame from the server with the RST,ACK bits set most likely), the server will respond with a SYN-ACK:
Server sends SYN/ACK --> Client
If the client received this packet, he will acknowledge he received it. This completes the three-way handshake and these two may begin exchanging information.
Client sends ACK --> Server
Here's a good site for some info:
http://www.tcpipguide.com/free/index.htm
I am new to networking.So I need to know the relations between sockets,IP, protocols(TCP/UDP), what is a socket for,and few other related words. I'm just trying to figure out how it works and want to learn. Can anyone help. at least put some links so that i can follow them. need it soon if possible
More elaborate information here : https://en.wikipedia.org/wiki/Internet_protocol_suite
Concise:
Your computer is on a LAN, that LAN is very likely to run on Ethernet.
On top of this Ethernet runs another protocol, IP.
On top of IP run several other protocols 2 of them are TCP and UDP.
UDP and TCP are multiplexing multiple communication channels that are each distinct on top of the same wire. It is doing that by using port numbers which are part of the protocol and which you can find in their respective header.
TCP and UDP are very much different:
TCP is Connection oriented whereas UDP is not.
UDP uses packets whereas TCP is a byte streaming protocol
TCP is reliable whereas UDP is not
other differences, this list is not exhaustive
To make TCP and UDP accessible to programs there is an application interface based on sockets. So you need a socket if you want to send or receive something.
https://en.wikipedia.org/wiki/Berkeley_sockets
But this is very broad topic and if it is your intention to start using this technology then you have to do a lot of reading.
What is the difference between a TCP server/Net server in vertex and HTTP server?
What are the use cases for each?
I tried googling and went through the official website, none of them have a clear explanation.
First off, in General Networking, there are 2 common types of handling connections. This can be done either over TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). The most import difference between these two is that UDP will continuously send out streams/buffers of bytes without checking to see if the network packets made it to the other side of the line. This is useful in situations where security isn't much of an issue and where speed is important. Most VoIP services (Skype, Hangouts), XMPP (chat) and even YouTube (I think) use UDP for their streaming, as it has huge gains on performances and it doesn't matter all that much if a frame made it to the other side of the line, as the person could simply repeat themselves.
TCP on the other hand, is "secure" by default. It performs several handshakes on a regular basis with the endpoint so maintain connectivity and make sure that all packets are received on the other side of the line.
Now, there are a LOT of protocols out there in the Wild Wild West called Internet.
List of TCP and UDP port numbers
As you can see, a lot of protocols support either TCP or UDP. HTTP on it's own is a TCP protocol with port 80 (as you might know). Therefore, HTTPServer is pretty much just an extension of a TCPServer, but with some add-ons such as REST. These add-ons are much welcome as HTTP processing is a pretty common use case. Without HTTPServer, you would need to declare loads of functions on your own.
There are many articles online explaining the difference between HTTP and TCP, so here is: http://www.differencebetween.net/technology/internet/difference-between-tcp-and-http/
Vert.x naturally offers the capacity to do "raw" networking at TCP level or at HTTP-level, the latter offering facilities to deal with the protocol, including decoding TCP packets into HTTTP requests, supporting the creation of HTTP responses, ...
I need to implement a client server architecture where the server sends
the same message to many clients over the internet.
I need to send a single message every 5 minutes about.
The message won't excede 5KB.
I need the solution to scale to a big number of clients connected (50.000-100.000)
I considered a bunch of solutions:
TCP Sockets
UDP Multicast
WCF http duplex service (comet)
I think I have to discard UDP solution because it is a good solution only for clients on the same network and it won't work over the internet.
I read somewhere that WCF multicast will cause a bottleneck if I have many clients connected but I can't find anywhere documentation showing performance statistics.
Tcp sockets seems to me the solution to chose.
What do you think about? Am I correct?
I'm certainly wrong when I say UDP doesn't work on internet... I thought
this because I read some articles pointing out that you need properly
configured routers in the network to support multicasting... I read of the
udp ports multicast range and thought it was meant to be locally.
Instead, the range 224.0.0.1 - 239.255.255.255 (Class D address group), can be reached over the internet
Considering that in my case reliability is not a crucial point, the udp multicast is a good choice.
The .net framework offers really helpful classes to accomplish this.
I can easily start an UdpClient and begin send data on a multicast address with two lines of code.
At client side it is really easy to.
There is the UdpSingleSourceMulticastClient class that does exactly what I need.
For what concernes reliability and security the .net framework has a smart and simple way of handle DoS attacks, DNS Rebinding attacks and Revers tunnel attacks that is described here: http://msdn.microsoft.com/en-us/library/ee707325(v=vs.95).aspx
The main question is: Do you care if the updates get to the clients?
If you DO then you will need to build something on top of UDP to add reliability. UDP datagrams are NOT reliable and so you should expect that some wont get to the destination. This is more likely if you are pushing UDP datagrams out quickly. Note that your clients might also get multiple copies of the same datagram in some situations with UDP.
50-100k connections with this level of traffic shouldn't be that difficult to achieve with TCP if you have a decent architecture.
See here for some blog posts that I've done on the subject.
http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html
http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-or-more-concurrent-tcp-connections---part-2---perf-tests-from-day-0.html
http://www.serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html
And here's some example code that deals with sending data to many clients.
http://www.serverframework.com/ServerFramework/latest/Docs/examples-datadistributionservers.html
Unicast (tcp sockets) will work fine for a relatively small amount of traffic such as this, but keep on top of multicasting technology, the situation is changing every year.