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.
Related
I am working on making a port scanner . I can check whether ports are open or not by trying to make a connection with the port but, how I will check the open port is udp or tcp?
... how I will check the open port is udp or tcp?
What you seem to have in mind is a single street where the ports are house numbers and in each house TCP and/or UDP might live. And you knock on the door and then need to figure out if UDP or TCP opened the door. But this view is wrong.
It is more like two separate streets which just have the same house numbers. There is one street for TCP and another for UDP and you decide which street to walk by choosing the type of socket. No need to check who is living in there since in the TCP street only TCP can live and in the UDP street only UDP.
A TCP socket gets created with AF_INET (or AF_INET6) and SOCK_STREAM. A UDP socket uses SOCK_DGRAM instead of SOCK_STREAM. So you know by creating the socket what you expect, i.e. which street to walk.
Apart from that UDP does not have the concept of an actual connection: while one can connect a UDP socket this will set the destination address on the local socket. It does not actually send any data to the peer to establish a connection like done with TCP. Thus a connect on a UDP socket will basically always succeed, no matter if something is expecting traffic on the destination (i.e port is "open") or not.
A single port can have any number of services running on it, using different protocols. Connecting only means that you connected with a specific protocol, and you'll need to check the other(s).
So, while it's probably unsatisfying as an answer, if you've been probing with TCP, you've probably never found a UDP service, and vice versa. And if you've been probing with XTP or something similarly obscure you've probably never found an open port.
Of course, be careful. "Connection" has different meanings under different protocols, particularly the stream-oriented protocols like TCP. You might have "connected" in an informal sense (provoked the server to acknowledge you), but you may not be "connected" in the sense of establishing a connection where the you definitely have the server's attention.
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?
I am building an application that will deploy in effect on multiple "clients" with a common "server". Clearly I could communicate between each client and the server using a single read-write socket for each client-server link, or a read socket and a write socket per link if I really wanted to.
But what if there are (hopefully good) reasons that the server wants to read from any client, and broadcast back to all? If you have a connectionless protocol like UDP, can the server use only a single read-write socket, or must it use one for reading and one for writing? What about the clients? And does this change if you use a connection-based protocol like TCP?
If you have a connectionless protocol like UDP, can the server use only a single read-write socket, or must it use one for reading and one for writing? What about the clients? And does this change if you use a connection-based protocol like TCP?
A socket as an endpoint which has at least a local address and port in case of UDP and TCP. Only data received for this ip and port are delivered to the socket and all data send from this socket contain the local ip and port as the source. A socket can be connected, in which case also the destination IP and port is known. With TCP a socket needs to be connected, with UDP not.
This means:
You can use the same unconnected UDP socket to send data to multiple peers (destination is an argument for the sendto function). You cannot do this with TCP, i.e. you need a connected socket for each single peer.
You can receive data from multiple peers on an unconnected UDP socket. You cannot do this with TCP.
The special broadcast address can be used with UDP but not with TCP, since with TCP you need to have a connection between only two clients which is not the case with broadcast.
See also a related question with answer for more information: Bidirectional UDP Multicast
But what if there are (hopefully good) reasons that the server wants
to read from any client, and broadcast back to all?
Well, then you'd probably want to use a UDP socket (either instead of, or in addition to, some TCP sockets) :)
If you have a connectionless protocol like UDP, can the server use
only a single read-write socket, or must it use one for reading and
one for writing?
A single UDP socket is sufficient for both reading and writing (although some multithreaded designs might find it easier to use two separate sockets instead; either way will work).
What about the clients?
Clients can also use a single socket for both sending and receive UDP packets, if that's what you're asking.
And does this change if you use a connection-based protocol like TCP?
With TCP sockets you can also use a single socket for both sending and receiving. However you will need one TCP socket for each destination that you want to send or receive to/from. (Contrast this with UDP where a single UDP socket can be used in conjunction with sendto() or recvfrom() to communicate with multiple peers)
As per your requirement, you have two ways :
By using TCP connection only : Server reads message from client and for the broadcasting to all clients,server writes message to all client's TCP sockets(connected to clients) and clients read that message from TCP socket(connected to server).This method requires that client and server knows the IP addresses of each other
By using TCP connection for the client-server direct communication and UDP for broadcasting : In this method,client and server communicates (directly one to one) using TCP connection. For broadcasting the message, server can broadcast the message over the network using UDP socket and clients have UDP broadcast receiver for receiving the broadcast message.
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 have no experience with sockets nor multiplayer programming.
I need to code a multiplayer mode for a game I made in c++. It's a puzzle game but the game mode will not be turn-based, it's more like cooperative.
I decided to use UDP, so I've read some tutorials, and all the samples I find decribes how to create a client that sends data and a server that receives it.
My game will be played by two players, and both will send and receive data to/from the other.
Do I need to code a client and a server?
Should I use the same socket to send and receive?
Should I send and receive data in the same port?
Thanks, I'm kind of lost.
Read how the masters did it:
http://www.bluesnews.com/abrash/chap70.shtml
Read the code:
git clone git://quake.git.sourceforge.net/gitroot/quake/quake
Open one UDP socket and use sendto and recvfrom. The following file contains the functions for the network client.
quake/libs/net/nc/net_udp.c
UDP_OpenSocket calls socket (PF_INET, SOCK_DGRAM, IPPROTO_UDP)
NET_SendPacket calls sendto
NET_GetPacket calls recvfrom
Do I need to code a client and a server?
It depends. For a two player game, with both computers on the same LAN, or both on the open Internet, you could simply have the two computers send packets to each other directly.
On the other hand, if you want your game to work across the Internet, when one or both players are behind a NAT and/or firewall, then you have the problem that the NAT and/or firewall will probably filter out the other player's incoming UDP packets, unless the local player goes to the trouble of setting up port-forwarding in their firewall... something that many users are not willing (or able) to do. In that case, you might be better off running a public server that both clients can connect to, which forwards data from one client to another. (You might also consider using TCP instead of UDP in that case, at least as a fallback, since TCP streams are in general likely to have fewer issues with firewalls than UDP packets)
Should I use the same socket to send and receive?
Should I send and receive data in the same port?
You don't have to, but you might as well -- there's no downside to using just a single socket and a single port, and it will simplify your code a bit.
Note that this answer is all about using UDP sockets. If you change your mind to use TCP sockets, it will almost all be irrelevant.
Do I need to code a client and a server?
Since you've chosen to to use UDP (a fair choice if your data isn't really important and benefits more from lower latency than reliable communication), you don't have much of a choice here: a "server" is a piece of code for receiving packets from the network, and your "client" is for sending packets into the network. UDP doesn't provide any mechanism for the server to communicate to the client (unlike TCP which establishes a 2 way socket). In this case, if you want to have two way communication between your two hosts, they'll each need server and client code.
Now, you could choose to use UDP broadcasts, where both clients listen and send on the broadcast address (usually 192.168.1.255 for home networks, but it can be anything and is configurable). This is slightly more complex to code for, but it would eliminate the need for client/server configuration and may be seen as more plug 'n play for your users. However, note that this will not work over the Internet.
Alternatively, you can create a hybrid method where hosts are discovered by broadcasting and listening for broadcasts, but then once the hosts are chosen you use host to host unicast sockets. You could provide fallback to manually specify network settings (remote host/port for each) so that it can work over the Internet.
Finally, you could provide a true "server" role that all clients connect to. The server would then know which clients connected to it and would in turn try to connect back to them. This is a server at a higher level, not at the socket level. Both hosts still need to have packet sending (client) and receiving (server) code.
Should I use the same socket to send and receive?
Well, since you're using UDP, you don't really have a choice. UDP doesn't establish any kind of persistent connection that they can communicate back and forth over. See the above point for more details.
Should I send and receive data in the same port?
In light of the above question, your question may be better phrased "should each host listen on the same port?". I think that would certainly make your coding easier, but it doesn't have to. If you don't and you opt for the 3rd option of the first point, you'll need a "connect back to me on this port" datafield in the "client's" first message to the server.