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 8 years ago.
Improve this question
I am learning about sockets and client-server applications. It seems as if the recommended approach is that the server should have a fixed IP address so that the client can find it. Is this correct? It seems as if there should be some type of startup technique where on initialization a program on the server (or the client) could generally broadcast their IP addresses to the other computers on the network, so that in case the server IP address changes the clients can still find it. Is this possible? I believe that "multicast" may be helpful, but it seems as if that is not always supported and/or the routers/switches must be configured to accept this or the technique would fail. Is this correct? I see that there are ways to perhaps use UDP to broadcast to any computer on the network, but it's not clear to me how the recipient computers can access this in a clear manner without a socket already set up - wouldn't there be confusion if other computers are already broadcasting on the same port? Is it just a protocol issue for the program to sort out to recognize the received packets? Do I just need to learn more about sockets? Any and all suggestions/pointers for where I could look would be greatly appreciated. Thanks so much in advance!
I am learning about sockets and client-server applications. It seems
as if the recommended approach is that the server should have a fixed
IP address so that the client can find it. Is this correct?
Yes, it is.
It seems as if there should be some type of startup technique where on
initialization a program on the server (or the client) could generally
broadcast their IP addresses to the other computers on the network, so
that in case the server IP address changes the clients can still find
it. Is this possible?
Yes, it is.
I believe that "multicast" may be helpful, but it seems as if that is
not always supported and/or the routers/switches must be configured to
accept this or the technique would fail. Is this correct?
No, multicast is not really helpful here, you mentioned why, and you should know multicast address in advance.
I see that there are ways to perhaps use UDP to broadcast to any
computer on the network, but it's not clear to me how the recipient
computers can access this in a clear manner without a socket already
set up - wouldn't there be confusion if other computers are already
broadcasting on the same port?
You just advertise your clients once in a while, for example every 5 secs or every 1 min, whatever interval you find ok. If someone sends on this port too - then you should use some unique structure, magic numbers and so on to distinguish one packets from another.
Is it just a protocol issue for the program to sort out to recognize
the received packets?
Yes, it is. On UDP.
Do I just need to learn more about sockets?
Absolutly yes. I suggest this book: Unix Network programming, it is good, even if you running non-UNIX environment.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
As TCP contains a checksum, and the TCP/IP stack will detect broken packets, is it redundant to add an extra checksum or CRC in a TCP payload (I mean the user data which could be read out by the socket api on the remote end), to make it possible for the receiver verify whether the data is same with the sent one?
Some thought about this question:
It's very common seen that there is a SHA256 value to verify the consistency when downloading files from internet.
The checksum contained in TCP packets already could detect broken packets in most cases.
The Modbus protocol for TCP dropped the CRC, which is used by the Modbus protocol for serial because there is already a checksum in TCP packets.
So, I am really confused now. Could somebody shed some light on this question?
I have googled, it's really not a new question, but the answer is still not clear, there are two opposite voices about this question.
For details, see these:
CRC checking done automatically on Tcp/Ip?
Is it possible for packets sent using TCP to ever arrive with different data?
ADDED:
The two questions aforementioned have been there for more than ten years! But there are still two opposite voices.
TCP has a checksum, which provides only some protection, simply because the checksum is only 16bit. For how much robustness the TCP checksum actually provides, or how much it is lacking, see Can a TCP checksum fail to detect an error? If yes, how is this dealt with?.
If you need more protection, you need to have additional and longer protection, because the more bits are used in protection, the better protection can be provided. If you need protection against active tampering with the traffic (ie not just accidental errors), you also need a cryptographic protection, such as offered by TLS.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I always hear about the layers of internet and i vaguely understand this. But, what confuse me most is that transport layer (including TCP protocol) lies on top of the internet layer(including IP protocol)..
What does this mean? For one who has a foggy understanding of the internet mechanism (I'm not a CS student or something I am just a hobby programmer)
The picture I have about the internet is that the network card sends/receives signals (packets) from the internet through wired connection / wifi then the OS using socket API sends/receives these packets acting as a layer between the hardware and the application which in turn uses some high-level protocol such as HTTP to interpret the data transferred - these protocol usually provided by languages e.g. python or java
.. I guess then that IP and TCP protocol are used at the level of the socket API? but I need more details ? I hope the explanation be in terms of coding/programming/implementation because abstractions used in this area confuse me.
Thank you , and sorry for my bad English
This is part of a layered solution to solve networking. Each layer has its own functionality:
IP (Internet Protocol) is in charge of delivering a packet (or datagram) from one interface, in one machine, with an IP address assigned to another interface in the same or other machine (node). Both nodes can be in the same LAN or different LAN connected through different paths (LAN's and routers). Basically it will make the packet get from source IP to destination IP. It provides a best-effort services, it doesn't assure the IP packet is going to arrive, it can be lost in the middle.
Above layer 3 or IP in the so-called TCP/IP stack, there is the transport layer. Its main functionality is to multiplex the lower layer (IP) service (take a packet from src to dst) among different applications. This is why in all transport layer protocols there is the concept of port or more generically Transport Service Access Point (TSAP). UDP, TCP, SCTP do that. UDP provides an unreliable service to the application. TCP provides a connected, reliable transport service to the application. This layer will make a message sent from application A in node Y reach application A1 in node Z, either reliably or unreliably (while IP only takes care of carrying the packet from node Y to node Z).
You will need to read a little about the OSI layered model and the TCP/IP layered model.
If you need to get more info I can address you to a training I have about IPv6 with a good introduction to networking: http://www.slideshare.net/rodolk/networking-tcpip-stack-introduction-ipv6
TCP is a protocol, known as "Transmission Control Protocol" - by specification it has features in place which makes sure that transmitted data is checked. On the other hand, there are things such as UDP, aka "User Datagram Protocol" which also works on top of IP - by specification this method does not check any transmitted data, so it's less useful where files must be fully intact (more utilised for video streaming, where some lost frames is acceptable, as opposed to binary file transfers where incorrect data means corruption and the whole file would be useless).
On to IP, IP is an addressing protocol, allowing a network to address and communicate with any machine that lives within it. IP stands for Internet Protocol, and it defines the fundamental way that two machines communicate over the "internet". It does not define how communications are handled, in ways such as being checked for data integrity, etc.
So, to summarise, the TCP and UDP are just extensions of IP. It is entirely possible, however, to have a socket based TCP or UDP connection, and I expect it's also possible to have some sort of MAC address protocol (as opposed to an IP address protocol). I don't know of any protocols which are similar to IP, but I imagine they do exist. In reality, using TCP over something other than IP is entirely unlikely. If you're going to the effort to create a custom protocol, chances are you'll want it fully custom and won't want to stick to design specifications designed for another protocol layer.
Note that calling it a "TCP/IP" connection is probably only ever used for legacy reasons. A lot of terms like this still exist because before the technology "bubble" growth, there were competing alternatives to IP. Even today, there is IPv6 which is technically an alternative to IPv4. It's also possible that we might one day outgrow IPv6, and at that point in time, there could be something other than IP to worry about.
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
I need to set ip from outside of virtual machine.
Now we use dhcp server to bind static ip with their MAC.
But when the number of vms is larger and large, that's not easy for administer.
I want to make one interface for the clients to set the ip of the vm when creating it.
By now, i know i can mount the vm disk and config the network setting before creating the vm.
there is one problem for that, the vm disk type may be various, and sometimes they may have totally different partition structure, and may be including LVM,etc. Besides this, i don't know whether it is possible to config ip for Windows operating system with this method.
I don't know how they do this, i mean those Virtual-machine product, like Vmware.
Edit:If those virtual-machine product don't give one interface for client to set ip for vm, then how they manage their ips. we have many many vms, and we specify ip for each of them, the client just use it, they are not authorized to set their ip from within the os, though set, it won't make any sense, they will can't connect to the internet.
I think there must be one approach for this.
Thanks, any help is appreciated.
First of all VMWare does not provide a way to set the IP for the host from it's interface. At least not a general way. If you really want to modify the guest filesystem have a look at libguestfs which provides tools and an api to modify guest images.
You may also want to have a look at foreman smart proxy to manage/control your dhcp server via a REST api. If you use directly theforeman it will allow you to manage the ip addresses via a webui.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have just installed xampp 1.7.7. I need to know what I need to do in order to make my website public using my public IP address (not 192.168.xxx.xxx) Also, I am behind a router (NETGEAR WPN824v3). I do have a dynamic IP address, but I have reserved the IP via my router. My operating system is Windows 7 Professional x64.
Do I need port forwarding? --> If so, what is the server IP (won't let me choose anything besides 192.168.xxx(cannot change).xxx(needs to be entered manually))? and what is the start port and end port?
What other changes do I need to make to make my website public without using:
127.0.0.1, 192.168.xxx.xxx,localhost,etc....
How do I configure a domain name (from DOT TK)?
Please give me a step-by-step detailed list of instructions on how to do this and don't refer me to other websites please!
Q: This sounds like a home network, correct?
Q: Do you have a registered domain? Or do you want people to access your site by IP address?
Your internal, LAN address is 192.168...
You can find your external ("WAN") address by looking at your router (which may be the Netgear, or might be yet another router - the one built in to your DSL or cable modem).
You can also find it by pointing your browser here:
http://www.whatismyip.com
Be advised that, unless you have a "static IP" from your provider, this external address might change at any time. It might stay the same for months ... or it might change multiple times/day. "It depends".
Be advised, too, that the moment you open anything on your firewall - especially a web site - you leave yourself potentially vulnerable to hackers. You absolutely need to make sure you have adequate security in place to protect against this eventuality.
Suggestion: look at DynDNS (or alternatives):
http://www.dyndnscommunity.com/
Or just shop around for a web hosting service that appeals to you :)
How do I register my domain(I don't want to use an ip address for my
name)
http://www.no-ip.com/ (free)
Is it possible to multiplex sa ocket connection?
I need to establish multiple connections to yahoo messenger and i am looking for a way to do this efficiently without having to hold a socket open for each client connection.
so far i have to use one socket for each client and this does not scale well above 50,000 connections.
oh, my solution is for a TELCO, so i need to at least hit 250,000 to 500,000 connections
i'm planing to bind multiple IP addresses to a single NIC to beat the 65k port restriction per IP address.
Please i would any help, insight i can get.
**most of my other questions on this site have gone un-answered :) **
Thanks
This is an interesting question about scaling in a serious situation.
You are essentially asking, "How do I establish N connections to an internet service, where N is >= 250,000".
The only way to do this effectively and efficiently is to cluster. You cannot do this on a single host, so you will need to be able to fragment and partition your client base into a number of different servers, so that each is only handling a subset.
The idea would be for a single server to hold open as few connections as possible (spreading out the connectivity evenly) while holding enough connections to make whatever service you're hosting viable by keeping inter-server communication to a minimum level. This will mean that any two connections that are related (such as two accounts that talk to each other a lot) will have to be on the same host.
You will need servers and network infrastructure that can handle this. You will need a subnet of ip addresses, each server will have to have stateless communication with the internet (i.e. your router will not be doing any NAT in order to not have to track 250,000+ connections).
You will have to talk to AOL. There is no way that AOL will be able to handle this level of connectivity without considering cutting your connection off. Any service of this scale would have to be negotiated with AOL so both you and they would be able to handle the connectivity.
There are i/o multiplexing technologies that you should investigate. Kqueue and epoll come to mind.
In order to write this massively concurrent and teleco grade solution, I would recommend investigating erlang. Erlang is designed for situations such as these (multi-server, massively-multi-client, massively-multithreaded telecommunications grade software). It is currently used for running Ericsson telephone exchanges.
While you can listen on a socket for multiple incoming connection requests, when the connection is established, it connects a unique port on the server to a unique port on the client. In order to multiplex a connection, you need to control both ends of the pipe and have a protocol that allows you to switch contexts from one virtual connection to another or use a stateless protocol that doesn't care about the client's identity. In the former case you'd need to implement it in the application layer so that you could reuse existing connections. In the latter case you could get by using a proxy that keeps track of which server response goes to which client. Since you're connecting to Yahoo Messenger, I don't think you'll be able to do this since it requires an authenticated connection and it assumes that each connection corresponds to a single user.
You can only multiplex multiple connections over a single socket if the other end supports such an operation.
In other words it's a function protocol - sockets don't have any native support for it.
I doubt yahoo messenger protocol has any support for it.
An alternative (to multiple IPs on a single NIC) is to design your own multiplexing protocol and have satellite servers that convert from the multiplex protocol to the yahoo protocol.
I'll trow in another approach you could consider (depending on how desperate you are).
Note that operating system TCP/IP implementations need to be general purpose, but you are only interested in a very specific use-case. So it might make sense to implement a cut-down version of TCP/IP (which only handles your use-case, but does that very well) in your application code.
For example, if you are using Linux, you could route a couple of IP addresses to a tun interface and have your application handle the IP packets for that tun interface. That way you can implement TCP/IP (optimised for your use-case) entirely in your application and avoid any operating system restriction on the number of open connections.
Of course, it's quite a bit of work doing the TCP/IP yourself, but it really depends on how desperate you are - i.e. how much hardware can you afford to throw at the problem.
500,000 arbitrary yahoo messenger connections - is your telco doing this on behalf of Yahoo? It seems like whatever solution has been in place for many years now should be scalable with the help of Moore's Law - and as far as I know all the IM clients have been pretty effective for a long time, and there's no pressing increase in demand that I can think of.
Why isn't this a reasonable problem to address with hardware plus traditional solutions?