Hosting a server

To host a server, use this minimal example:

Start of frame, host on port 6121. On error, add line to list. On connect, add line with Client IP expression to list.


As a side note, you should never report errors in a way where the last error is erased to put the new one in its place, otherwise repeating errors and errors that occur close in time to each other are hidden.

For example, setting a String object to display the error breaks this rule.

Read more about proper error reporting on Tips.


How do you connect to your server? Your choices depend on where the machine you are using to connect from is located, as there are different IP addresses depending on how the client and server machines share a network. Read more below.

Networking levels

There are three levels of networking your app has, or how accessible it is.

Local host (loopback)

By default, by simply using the Lacewing Blue/Relay Server object's Relay Server > Host action, the Relay Protocol server will be available to the same computer it's hosting on.


Connecting to the localhost address "localhost", the loopback IP address "127.0.0.1" (IPv4) or "::1" (IPv6), will result in the client program trying to connect to a server on the same machine it's on.

This is called loopback, because the connection from the client program is outgoing and loops back to the server program as an incoming connection, without leaving the machine.


You can use a loopback connection even without a network connection, making it useful for testing.


However, if you're looking to connect with other machines, you'll need to read on to the LAN explanation following.

Local area network (LAN)

LAN, or local area network, is the shared network of all the devices connected to the same router. These devices all have unique local IP addresses, otherwise known as LAN IP addresses.


To enable LAN access for your server program, all you need to do is add the server program to the server machine's firewall settings, so it can accept incoming connections.

Generally, when you first start hosting the server, Windows Firewall will pop up after blocking it, and ask whether you want to allow it. This is normal to all server programs, including LAN multiplayer games.


If you have a third-party antivirus, not Microsoft's built-in one, there is a possibility your antivirus on the server machine will have its own settings independent of the Windows Firewall, causing the antivirus to block incoming/outgoing connections, so check that the antivirus has it unblocked too.

For example, Windows Firewall might be set to allow the hosting/connection but Avast/Norton/etc. is blocking it.


You can connect to the server program on your server machine, from any device in the LAN, by connecting to the server machine's local IP address, with the port you are hosting on.


You can look up the local IP of a machine using Fusion extensions like LocalIP++, or by running Command Prompt and using the ipconfig command, on the server machine.

Be careful you don't run it on the client machine, it'll give an IP that is irrelevant. You want the hosting machine's IP.


Command Prompt window, running ipconfig. Shows IPv4 address line, followed by a 192 address.

Example of ipconfig.Typically, local IPs start with 192.168.x.x, or 10.x.x.x, or 172.x.x.x.


Using the above example, clients on the network need to connect to "192.168.1.111:6121", if you're hosting on port 6121.

There may be multiple network adapters; don't use an adapter with "virtual", "loopback" or "vpn" in the name, and remember "Ethernet" means a plug-in wired adapter.


The LAN IP will also work for the server machine connecting to itself, so you can run a test client on your server machine and connect to your LAN IP to see if it works.

  • If the server machine connecting to its own LAN IP fails, you're using the wrong IP address to connect to.
  • If it works, but another client on the network can't connect, then the other client is probably using the wrong IP address, or hasn't allowed the client program on its firewall.
    Again, the firewall prompt should appear the first time you try to connect, as the firewall blocks it. If you miss the dialog, go into the Windows Firewall control panel option. If you have antivirus, also check it has the application allowed.

Long-term hosting on LAN/internet

If your local IP address is dynamic (described below), then the router uses a technology called DHCP which assigns your LAN device a local IP, which expires and is refreshed every x hours or days.

Normally, the router keeps these assigned IPs the same if the server machine is consistently connected, but it may reassign a different IP address, if the server machine goes offline for too long, or if the router is restarted.


You needn't worry about your IP address changing, or keeping your local IP as a fixed address, unless you plan to host for days or longer, or expect to go offline on your LAN.

In that case,

  • if using Windows 10, then look into how to assign a static local IP for your LAN network here
  • or if using earlier than Windows 10, how to assign a static local IP on your network adapter here.
    Note that will apply to all networks you use for that adapter, which will mean if you set a static IP up for your WiFi at home, then go to another building, like your workplace or education, and try to use their WiFi, you may not be able to get on!
    The same applies to wired, if you plug in at both home and away. You'll have to manually reset the adapter back to normal in order to use the other networks.
  • It is also possible to set up a static IP assignment in the router's settings, based on MAC address of the server machine's network card, but that's not on all router firmware; you'll have to google how to do it for your router model.

Internet

First follow the steps for LAN hosting and long-term hosting above, then continue reading this section.


Internet hosting has a couple extra steps.

First, you'll have to look up router port forwarding, so internet-originating connections can be passed from outside of your router to the local IP of the server machine on your LAN.

In your router's settings page, you'll have to unblock any ports in use.

  • Lacewing Relay Server: unblock the Lacewing Relay port on both TCP and UDP, and unblock the Flash policy port if you're using that; Flash policy uses TCP 843, always.
    Typically Lacewing Relay/Blue Server uses port 6121, but you specify it in the Relay Server > Host action.
  • Lacewing Webserver: the typical port for HTTP is TCP 80, and HTTPS is TCP 443.


If your router asks for both internal and external port, then use the same port numbers for both of them.


After port forwarding on the router, you should have access from anywhere on the internet to your Relay/Blue Server.


Test it by attempting a connection via your remote IP address; you can find your remote IP on this webpage, or from a simple Google search "what is my IP".

When connecting, don't forget to put in the port; see examples of how under the Relay Client > Connect action.


If a connection to your remote IP fails, but connection over LAN (by connecting to local IP) works, you may have your Internet Service Provider (ISP) blocking incoming connections on their firewall before it even reaches your router.

For the ISP to unblock, you will have to talk to your ISP to get it unblocked, or use their control panel settings.

Internet hosting via domain

If you are trying to use a domain, so "example.com" goes to your server, you will have to sign up with a DNS provider. DNS providers maintain lists of domains and their remote IPs.

DNS hosting is normally a paid service, usually $5-15 a year. DNS hosters will not hide your remote IP address; it is necessary to give that to clients to connect to.

DNS registrations are usually required to give a physical address as well, like the building the server is in, so be aware of your privacy. Some providers offer to hide your details, usually for extra cash.

Static and dynamic IP

A static IP address is an IP that is kept the same by your Internet Service Provider (ISP) regardless of whether the router reboots or otherwise disconnects from the ISP.

The opposite is dynamic IP, which can be changed by a router disconnect/reboot.


Usually, ISPs provide dynamic IPs, and give static IPs as a paid add-on to your ISP package.


If you do not use a static IP, then you will need to sign up to a dynamic DNS service (sometimes called DynDNS or DDNS), which your router may have built-in support for.

A DynDNS service will host its own DNS records, and update whenever your router's IP changes. They normally give you a subdomain of their main website (e.g. HopTo service may give you "yourusername.hopto.org"), and manage all requests to that subdomain by redirecting them to the router's IP, like a normal DNS would.

You can then connect on any computer to "yourusername.hopto.org" and get through to your Lacewing servers, provided you've done port forwarding and other steps described above.

DynDNS are often free, and automatic updating is built into some newer routers. A common DynDNS service is NoIP.com.


It is better to use a static IP for serious long-term hosting, as it will not use a third-party service or require you to use their domain.


It's worth noting IP addresses for a domain are cached, and if your IP changes, then any clients with that cached IP may fail to connect for several days, until their cached records expire.

It is possible to change how long DNS records are cached, and DynDNS make use of this feature, but without a cache the apps have to look up the IP each time.


You can clear your OS's DNS cache by using Command Prompt command ipconfig /flushdns.

Note that some web browsers use their own cache, which you can clear from browser settings – but this will only affect the HTTP/HTTPS Lacewing Webserver.

IPv6

An IPv4 address will always be in the format "###.###.###.###" as above, where ### are numbers between 0 and 255, inclusive.

An IPv6 address will be in four-digit hexadecimal (0-9, A-F) blocks separated by colons. As an example; "2001:0000:3238:DFE1:63::FEFB".


Due to IPv6's lengths, various shortening methods are applied; for example, 0063 will be reduced to 63, and whole blocks will be removed if not used.

IPv4 addresses mapped to IPv6 will look more like "::ffff:52e5:db02". Note that Blue will converted IPv4-mapped IPv6 addresses to their IPv4 counterpart for any IP expressions.

Relay doesn't support IPv6 due to bugs in the design, rather than by intention.


IPv6 is less widely adopted than IPv4, but is becoming more of a necessity, as many regions were assigned small IPv4 blocks that couldn't be distributed sufficiently. For example, India and Asia have too small a block of IPv4 to match their growing population and technology.

 Your ISP should support IPv6 connections, but if they do not, there is a good chance IPv6 clients can still access your server via technologies like 6to4 or Teredo tunneling (these are done by the client's ISP, and invisible to the end users). But these technologies aren't a fix-all and you run the risk of losing the clients that aren't able to use those, so you should try to find an ISP or hosting service that supports IPv6 natively.


For more reading on IPv6, see here. You can test if your computer can use IPv6 here.

Securing your server

You should read the Security and Tips topics to better secure and speed up your server.

There is also an example on IP banning in Security.

Setting up a VPS

If you are planning to buy a server machine, there are several points to consider:


  1. Check the server specs.
  • Supported OSes:
    If you're doing Windows Server OS, any Server OS version should work, from Windows Server 2003 and above.
    You can also write your own custom Windows server app in Fusion.
    For Fusion server events, see example at top of Guides > Hosting a server topic.
    Read Guides > Tips and Guides > Security to get it working fast and safely.

    If you're using Windows but don't need a custom server, use the faster bluewing-cpp-server, created by Darkwire Software, the creators of Lacewing Blue.
    The bluewing-cpp-server program uses C++ only, with no Fusion UI involved, so it's very fast.

    You can host from home, if your Internet Service Provider permits it, and you don't mind running your computer close to 24/7. You don't need a Windows Server OS; a standard Windows OS is fine. Refer to the above topics about how to make your server accessible from the internet.

    If you want non-Windows, you'll have to use third-party Lacewing server programs:
    • pylacewing, written in Python 2, by Mathias, and abandoned.
      For OS compatibility, check for Python 2 support.
    • RedRelay, written in C++, by LekKit
      Should perform faster than pylacewing.
      For OS compatibility, message LekKit to ask – he often will edit RedRelay to support your server if it's not too much work.
  • CPU cores:
    It's recommended you take a VPS that offers 2+ CPU cores. It's not required, but it helps.
    In the possible event one of your programs decides to use all available CPU space – for example, stuck in an infinite loop – then the remote access won't have any spare CPU to let you connect and debug the problem, and you won't be able to run anything like Task Manager. Multiple cores gives it that capacity.
  • CPU speed:
    Your CPU speed itself matters; Lacewing servers are fairly light-weight, with the bluewing-cpp-server particularly light. However, they are single-core programs, so they can only run as fast as one CPU core can run.
  • Bandwidth:
    As you're the creator of the client, presumably, then you can optimize the bandwidth usage. Games shouldn't need to send all that much; video calls are the biggest bandwidth requirement.
    Read the Guide > Tips on performance optimization; remember CPU usage and bandwidth are tied together, as % of CPU time spent processing messages increases for more messages, bigger messages, and for a slower CPU.
  • IPv6 support:
    A percentage of the Internet uses IPv6 only, so make sure your server supports it if you want full worldwide coverage.


Currently, Darkwire Software uses a Windows Server running bluewing-cpp-server, and a Raspberry Pi 3B running RedRelay, to host its public servers.


  1. Update the OS.

Once you get the OS, for security reasons, you should update the OS you're using to the latest available.


Disable automatic updating, unless you want your server going offline at random. Windows won't let you disable updates via the Windows Update settings, but you can disable the Windows Update service entirely.


Periodically, say 1-3 months, you should update your server OS again, manually.

Most Linux-based OSes won't automatically update by themselves. To manually update them, you typically have to use apt-get update followed by apt-get full-upgrade in a Terminal or SSH session. The exact method may vary per OS, but you can easily google it.


  1. If your machine has a password, consider changing it.

Also, consider adding a new user account to run your server programs in.

Don't lock yourself out of your new machine! Make sure you know what your password is.


  1. Get your server program copied onto the server machine.

You'll need remote access. Consider using a file-sharing app like Dropbox where you can regularly send new server versions.

You may want to use AnyDesk, or enable Remote Desktop Connection in Windows system settings, as both have file transfer capacity.

What is available will depend on your OS.

In a pinch, you could use a one-off file-sharing site, but those tend to have dodgy adverts.


  1. Set your server program as allowed in the firewall.

Some OSes automatically allow all outgoing connections, but refuse incoming ones. Make sure your server app is an exception on the firewall.


  1. Test your server program.

Try connecting to it using a Lacewing client, passing the server's remote IP – just look up "what is my IP" on Google from the server machine if you're not sure. Make sure to have the hosting port too.

Does it accept connections now? Don't leave it untested.


  1. Set your server program to start up again when the machine restarts.

In Windows, this can be achieved by the Task Scheduler.

In Linux-based OSes, this normally requires use of /etc/init.d, but it varies widely. Follow an online guide for your particular OS.


  1. Test the auto-restart on startup works.

Give it a bit of time, but don't leave it untested.

If you expect to remote access frequently, you can set up an auto-login such as using Sysinternals AutoLogon; do that at your own risk. If you're using Remote Desktop Connection, you won't need to do this, as it signs you in by itself.


And you're good to go!