Does SOA(Service Oriented Architecture) works properly within IPv6 network deployments? Are the freely existing tools(eg. eclipse, netbeans etc) to create web services takes care of IPv6 network addresses?
IPv6 works at layer 3, while SOA and applications work at layer 7, so that should be no problem. Not all applications and libraries are properly written though, so there might be implementation specific limitations. Tools like Eclipse and Netbeans work equally well for IPv4 and IPv6. They don't really care about the IP version.
Related
I'm working on a 2D top-down multiplayer game, and though I have thoroughly tested it on my LAN network, I would like to distribute it to some friends accross the world so they can test it too. I have read a few topics on hosting WAN servers but it's always for professional things or for websites, but I just want a simple server on which only few people will connect.
I started learning networking just a week ago, so I only know the basics, and if there's a way for them to connect directly to my computer somehow, I'd be happy to know.
I'm using Lua, Love2D and LuaSocket(UDP)
Networking is all about IP addresses. If you are trying to play with both IPv4 and IPv6, get your own IP address via http://whatismyip.live or whatismyip.host etc and (like sorak said) map it with free tools like noip.com . Websites will only give you external IP address. If you are looking for creating a LAN without internet then you would need to find IP address from the network settings.
Kubernetes has a pretty complicated networking model that appears to be predicated upon circumventing a critical flaw with Docker's default networking:
By default Docker containers cannot be contacted directly from the outside world, because their IP addresses are local/private to the subnet they're on.
To circumvent this, Kubernetes has a very complex network model that, amongst other things, requires you to carve out your own flat IP space that is then shared by all hosts and containers (pods), thus giving each pod its own public IP.
But I ask: isn't this already addressed by Docker port binding? If not, then what about port binding is still lacking, that requires Kubernetes to use the networking solution that they use?
This is well described in the motivation section of Kubernetes's networking design doc.
Essentially, relying on port binding requires dynamic port mapping to avoid conflicts between different containers wanting the same port (e.g. a lot of applications will want port 80). While dynamic port mapping can be made to work, it also causes a lot of problems, as outlined in the doc.
I'm trying to establish a TCP connection between a client machine and a guest VM running inside an ESXi server. The trick is that the guest VM has no network configured (intentionally). However the ESX server is on the network, so in theory it might be possible to bridge the gap with software.
Concretely, I'd like to eventually create a direct TCP connection from python code running on the client machine (I want to create an RPyC connection). However anything that results in ssh-like port tunneling would be breakthrough enough.
I'm theorizing that some combination of VMWare Tools, pysphere and obscure network adapters could be possible. But so far, my searches don't yield any result and my only ideas are either ugly (something like tunneling over file operations) and/or very error prone (basically, if I have to build a TCP stack, I know I'll be writing lots of bugs).
It's for a testing environment setup, not production; but I prefer stability over speed. I currently don't see much need for high throughput.
To summarize the setup:
Client machine (Windows/Linux, whatever works) with vmware tools installed
ESXi server (network accessible from client machine)
VMWare guest which has no NICs at all, but is accessible using vmware tools (must be Windows in my case, but a Linux solution is welcome for the sake completeness)
Any ideas and further reading suggestions would be awesome.
Thank you Internet, you are the best!
It is not clear the meaning of 'no NICs at all on guest'. If I can assume that, there is no physical NICs assigned for the guest is what is meant here. The solution is easy as a vmWare soft NIC can be provisioned for the guest VM and that will serve as the entry point to the guest netstack.
But if the soft NIC is also not available, i really wonder how and what can serve as the entry point to the netstack of guest, be it Linux/Windows. To my understanding, if thats what you meant, then you might need to make guest OS modifications to use a different door to access the guest netstack and to post/drain pkts from it. But again, when you do a proper implementation of this backdoor, it will become just another implementation of softNIC which vmware by default support. So, why not use that?
It's a bit late but a virtual serial port may be your friend. You can pick the serial port on the outer end via network or locally depending on your options. Than you can have some ppp stuff or your custom script on both ends to communicate. You could also run some tool to create a single socket from the serial link on the guest end if you want to avoid having a ppp interface but still need to tunnel a TCP connection for some application.
This should keep you safe when analyzing malicious code as long as it's not skynet :-) You still should do it with the permission of the sysadmin as you may be violating your company's rules by working around some security measurements.
If the VM 'intentionally' has no network configured, you can't connect to it over a network.
Your question embodies a contradiction in terms.
We're currently looking to migrate an old and buggy eucalyptus cloud to openstack. We have ~15 machines that are all on the same office-internal network. The instances get their network configuration from an external (not eucalyptus) DHCP server. We run both linux and windows images. The cloud is used exclusively for platform testing from Jenkins.
Looking into openstack, it seems that out of the three supported networking modes, none really fit our environment. What we are looking for is something like an "unmanaged mode" where openstack launches an instance that is hooked up to eth0 interface on the instances' compute node and which will receive its network configuration from the external DHCP on boot. I.e. the VM's, guest hosts and clients (jenkins) are all on the same network, managed by an external DHCP server.
Is a scenario like this possible to set up in OpenStack?
It's not commonly used, but the Networking setup that will fit your needs the best is FlatNetworking (not FlatDHCPNetworking). There isn't stellar documentation on configuring that setup to work through your environment, and some pieces (like the nova-metadata service) may be a bit tricky to manage with it, but that should accomplish allowing you to run an OpenStack cloud with an external DHCP provider.
I wrote up the wiki page http://wiki.openstack.org/UnderstandingFlatNetworking some time ago to explain the setup of the various networks and how they operate with regards to NICs on hosting systems. FlatNetworking is effectively the same as FlatDHCPNetworking except that OpenStack doesn't try and run the DHCP service for you.
Note that with this mode, all the VM instances will be on the same network with your OpenStack infrastructure - there's no separation of networks at all.
I'm writing TCP/IP code for a DHCP enabled network device. Is there a universal way this device can announce its hostname in-the-wild that pretty much all web browsers (on osx/linux/win) can access it by name? (e.g. http://mydevice/index.htm)
A solution that allows the end-user to use their "stock" computer without stringent requirements like installing packages such as bonjour for windows, have a dns server on their network, etc.
zeroconf/dns-sd doesn't work on windows machines that don't have bonjour (or similar) service installed and LLMNR doesn't work on osx machines out of the box.
If there is no single way of doing this, would conforming to both dns-sd and LLMNR cover most of the installed OS base out there?
From what I can gather, in order to cover hostname resolution in a dns-less network, ZeroConf/mDns/Dns-Sd and NetBios (NetBt) are required to cover windows based, and Osx based system (most linux systems also suppor ZeroConf).
NetBt doesn't support IpV6, and LLMNR is supported by Vista and onwards Microsoft developed operating systems. So a "universal" name resolution method might have to implement all three.