Throughout Guide to networking problems connecting from East Asia, Southeast Asia and Oceania [Part 1: Network routing]

[KLsz]

First, as a disclaimer, I'm not a specialist on network routing. I'm not a member of CubeCraft's Development Team or Admin Team either.
But I want to try to explain a little bit about how internet works and give you some suggestions to the thing.
Please notice that this is part 1 of a two-part document explaining networking problems. Part 2 is basically explaining problems happening under a high ping, which is available here -> www.cubecraft.net/threads/296047/ if you want to have a look at that as well.

Well, let's talked about the problems you might have had.​

Some of you from Asia or Oceania may have experienced a lot of networking problems playing CubeCraft. These problems come in different forms:

• You may not be able to bridge in EggWars, SkyWars or Lucky Islands because the blocks you have just placed under you are sometimes disappearing on itself.
• You may be kicked for timed out when joining MinerWare.
• You may lag in some locations and you can not move.
• You may be teleported to the sea when joining the Lobby.
• You may lose connection to the server when you are playing Survival Games, etc.

These are glitches that are not supposed to happen.

Well, you might say, are there any glitches that are indeed supposed to happen?
Yes, there are. For example, you might have experienced lagback issues when you are jumping to a block when that specific block is removed or covered by another player, or you might not be able to place a block in front of another player to give you a better position in pvp when playing EggWars, SkyWars or Lucky Islands. These are problems cause by a high ping, which I discuss in Part 2 of this document here -> www.cubecraft.net/threads/296047/ .

Let's back to the topic. These glitches are not supposed to happen. It is not something the developer wants. On programing, there are always some glitches we can't find out when we are trying our best to test out the program. Not until the final release of the program do those glitches eventually pop out. The problems above are mostly this kind of situation. It is triggered by a unstable internet connection on a glitchy program.

Let me introduce how your internet and your Internet Service Provider (ISP) works.​

Your Internet Serice Provider (ISP), is the company that provides you with internet access, to name a few, NTT Docomo, Chunghwa Telecom, Hong Kong Broadband Network, Singtel, Telstra and Spark NZ. These companies not only connect you to their backbone cable, but also negotiate with other ISPs around the world, to send your data through submarine cable to reach your destination.

Most of our connections to CubeCraft from East Asia, Southeast Asia and Oceania are transfered through a variety of submarine cables, passing the Continental United States, until it gets into some other submarine cables and finally reaches France, the place where CubeCraft servers are located.
You can have a vague idea of what those submarine cables are by looking at this image from www.submarinecablemap.com .

[Figure 1: Submarine cables connceting from Asia and Oceania through the US to Europe]​

As you can see, there are a variety of cables on this image. Those cables are actually not at a same level of stability. Some of them are actually much worse than another. When using some specific cables, you are very likely to get random lag spikes and all kinds of issues. Well, here comes your ISP, your ISP tried their best to find, to negotiate, or even to build a best submarine cable for you to use, but they might not manage to provide a cable you are satisfied with.

So, in order to solve the problems, here are my suggestions.​

Solution I: Connect to another server region.

---

If you are connecting to the EU region right now, try connecting to the NA region. If you are connecting to the NA region, try connecting to the EU region.
As you change your destination, your ISP will probably put you on a different cable in order for you to directly reach your destination. So that's a chance you may be able to use a better cable with fewer glitches. (Well, maybe the other cable are even worse than the one you are using right now.)

Pros: This is a free solution that does not require a single pence.
Cons: You may enjoy the gameplay at a different region with a different group of people, and you may not want to change.
Cons: If you are switching from the NA region to the EU region, you may have to add a couple of milliseconds to your ping as a result.

Solution II: Use another Internet Service Provider (ISP) (aka get better WiFi).

---

As is explained before, it is your Internet Service Provider that provide you with the specific submarine cable to use. You may want to change a ISP, as they may connect you to a different cable which might be a little bit better.
According to my own experience, the „most popular” and the „best” ISP in your region might not provide you with the best cable you want. You should definitely check out with your local gamer community to find out the best one for you.

Pros: If you have done enough researches, you may find the best ISP in your region to use. You will enjoy a much more stable connection.
Cons: In some case you can't decide yourself which ISP to use, for example if you are living with your parents, or if you are renting house outside.

[Figure 2: A cable connecting from Australia is provided by Telstra]​

Solution III: Buy a rank at CubeCraft and Buy a VPN.

---

Similar to Solution I, a VPN can reroute your connection. By connecting to a different location, you may be able to use a different cable to connect from your country to the VPN server. VPN provides you with a lot of choice; You can try their locations one by one to find out which one works the best for you.
On the other hand, in order to provide good VPN services, large VPN service providers tend to build their VPN servers on better internet backbones. That may help you with a more stable connection as well.

By the way, you do need a rank to connect to CubeCraft with a VPN, but I believe ranks won't be a problem if you can afford a VPN. And also CubeCraft is such a good server, why not reward the Team with some real world money?

Pros: It provide you with a lot of choice; You are very likely to find a cable that is very good.
Pros: You may be traveling around, but a good VPN service provider would probably let you find a good connection wherever you are.
Cons: It is expensive.

[Figure 3: Traceroute when connecting to a German VPN server]

[Figure 4: Traceroute when connecting to a Singapore VPN server]
​

 

[Ben]

Nice generic overview of how the internet works, it is a bit more complicated than that but this gives a visual quite nicely. We've changed some routing options for Asia/Oceanic players today so you may find that you have slightly better latency :) We're also still definitely looking into Asia regions but can't give any date yet :c

 

[Snowy54]

It is very interesting, I enjoyed this very much. Keep it up! :)

 

[KLsz]

Nice generic overview of how the internet works, it is a bit more complicated than that but this gives a visual quite nicely. We've changed some routing options for Asia/Oceanic players today so you may find that you have slightly better latency :) We're also still definitely looking into Asia regions but can't give any date yet :c

Thank you very much! Actually I basically knows nothing about network routing or programing. There are definitely a lot mistakes and a lot more details missing in this document. And also thank you very much for providing good connections for Asia/Oceanic players :)

 

[josepadgui]

First, as a disclaimer, I'm not a specialist on network routing. I'm not a member of CubeCraft's Development Team or Admin Team either.
But I want to try to explain a little bit about how internet works and give you some suggestions to the thing.
Please notice that this is part 1 of a two-part document explaining networking problems. Part 2 is expected to be ready before Sep 25 Sat.

Well, let's talked about the problems you might have had.​

Some of you from Asia or Oceania may have experienced a lot of networking problems playing CubeCraft. These problems come in different forms:

• You may not be able to bridge in EggWars, SkyWars or Lucky Islands because the blocks you have just placed under you are sometimes disappearing on itself.
• You may be kicked for timed out when joining MinerWare.
• You may lag in some locations and you can not move.
• You may be teleported to the sea when joining the Lobby.
• You may lose connection to the server when you are playing Survival Games, etc.

These are glitches that are not supposed to happen.

Well, you might say, are there any glitches that are indeed supposed to happen?
Yes, there are. For example, you might have experienced lagback issues when you are jumping to a block when that specific block is removed or covered by another player, or you might not be able to place a block in front of another player to give you a better position in pvp when playing EggWars, SkyWars or Lucky Islands. These are problems cause by a high ping, which I will discuss in Part 2 of this document. It is expected to be ready before Sep 25 Sat.

Let's back to the topic. These glitches are not supposed to happen. It is not something the developer wants. On programing, there are always some glitches we can't find out when we are trying our best to test out the program. Not until the final release of the program do those glitches eventually pop out. The problems above are mostly this kind of situation. It is triggered by a unstable internet connection on a glitchy program.

Let me introduce how your internet and your Internet Service Provider (ISP) works.​

Your Internet Serice Provider (ISP), is the company that provides you with internet access, to name a few, NTT Docomo, Chunghwa Telecom, Hong Kong Broadband Network, Singtel, Telstra and Spark NZ. These companies not only connect you to their backbone cable, but also negotiate with other ISPs around the world, to send your data through submarine cable to reach your destination.

Most of our connections to CubeCraft from East Asia, Southeast Asia and Oceania are transfered through a variety of submarine cables, passing the Continental United States, until it gets into some other submarine cables and finally reaches France, the place where CubeCraft servers are located.
You can have a vague idea of what those submarine cables are by looking at this image from www.submarinecablemap.com .

View attachment 200256

[Figure 1: Submarine cables connceting from Asia and Oceania through the US to Europe]​

As you can see, there are a variety of cables on this image. Those cables are actually not at a same level of stability. Some of them are actually much worse than another. When using some specific cables, you are very likely to get random lag spikes and all kinds of issues. Well, here comes your ISP, your ISP tried their best to find, to negotiate, or even to build a best submarine cable for you to use, but they might not manage to provide a cable you are satisfied with.

So, in order to solve the problems, here are my suggestions.​

Solution I: Connect to another server region.

---

If you are connecting to the EU region right now, try connecting to the NA region. If you are connecting to the NA region, try connecting to the EU region.
As you change your destination, your ISP will probably put you on a different cable in order for you to directly reach your destination. So that's a chance you may be able to use a better cable with fewer glitches. (Well, maybe the other cable are even worse than the one you are using right now.)

Pros: This is a free solution that does not require a single pence.
Cons: You may enjoy the gameplay at a different region with a different group of people, and you may not want to change.
Cons: If you are switching from the NA region to the EU region, you may have to add a couple of milliseconds to your ping as a result.

Solution II: Use another Internet Service Provider (ISP) (aka get better WiFi).

---

As is explained before, it is your Internet Service Provider that provide you with the specific submarine cable to use. You may want to change a ISP, as they may connect you to a different cable which might be a little bit better.
According to my own experience, the „most popular” and the „best” ISP in your region might not provide you with the best cable you want. You should definitely check out with your local gamer community to find out the best one for you.

Pros: If you have done enough researches, you may find the best ISP in your region to use. You will enjoy a much more stable connection.
Cons: In some case you can't decide yourself which ISP to use, for example if you are living with your parents, or if you are renting house outside.

View attachment 200257

[Figure 2: A cable connecting from Australia is provided by Telstra]​

Solution III: Buy a rank at CubeCraft and Buy a VPN.

---

Similar to Solution I, a VPN can reroute your connection. By connecting to a different location, you may be able to use a different cable to connect from your country to the VPN server. VPN provides you with a lot of choice; You can try their locations one by one to find out which one works the best for you.
On the other hand, in order to provide good VPN services, large VPN service providers tend to build their VPN servers on better internet backbones. That may help you with a more stable connection as well.

By the way, you do need a rank to connect to CubeCraft with a VPN, but I believe ranks won't be a problem if you can afford a VPN. And also CubeCraft is such a good server, why not reward the Team with some real world money?

Pros: It provide you with a lot of choice; You are very likely to find a cable that is very good.
Pros: You may be traveling around, but a good VPN service provider would probably let you find a good connection wherever you are.
Cons: It is expensive.

View attachment 200258
[Figure 3: Traceroute when connecting to a German VPN server]
View attachment 200259
[Figure 4: Traceroute when connecting to a Singapore VPN server]
​

It's a really interesting post for those who play from Oceania and many parts of Asia to the CubeCraft Network. I personally don't experiment this problems myself as I live very near to France, which is the country where CubeCraft hosts its Network.
I'm sure this will be really useful for many players Oceanic and Asian players that suffer similar problems.

 

[AM71113363]

Your Internet Serice Provider (ISP), is the company that provides you with internet access, to name a few, NTT Docomo, Chunghwa Telecom, Hong Kong Broadband Network, Singtel, Telstra and Spark NZ. These companies not only connect you to their backbone cable, but also negotiate with other ISPs around the world, to send your data through submarine cable to reach your destination.

this submarine cable is a FIBER OPTIC CABLE
The data travels at speed of light.

Solution II: Use another Internet Service Provider (ISP) (aka get better WiFi).

Agree.

---

Solution III: Buy a VPN.​

---

Similar to Solution I, a VPN can reroute your connection. By connecting to a different location, you may be able to use a different cable to connect from your country to the VPN server. VPN provides you with a lot of choice; You can try their locations one by one to find out which one works the best for you.

The VPN will use your ISP to connect to the remote Server, and again the ISP will negotiate with other ISPs around the world.

The VPN can help only by changing VPN Settings to allow conn only to MINECRAFT and not other Apps.

 

[KLsz]

The data travels at speed of light.

Yes, and I will discuss about the theoretical limit of ping in Part 2.

The VPN will your ISP to connect to the remote Server, and again the ISP will negotiate with other ISPs around the world.

I believe VPN will send all the data you are transferring to their server, before they forward your data to the destination. The only thing your ISP will be in charge of, is to get your data to and from the VPN server. By selecting a different VPN server, I believe your ISP has to find a new route to connect you to that server, thus giving the possibility to connect through another better cable.

 

[AM71113363]

The only thing your ISP will be in charge of, is to get your data to and from the VPN server.

Using VPN: flow_data
Client -> VPN -> ISP -> Remote Server -> Cubecraft.
And
Cubecraft -> Remote Server -> ISP -> VPN -> Client.

Without VPN: flow_data
Client -> ISP -> Cubecraft.
Cubecraft -> ISP -> Client.

NOTE:
This is only for Bedrock.
Java is another story.
I'm not against VPN, players are free to use whatever they want.

 

[AM71113363]

SUGGESTION:
When using traceroute with/without VPN, use the same IP instead of hostname.
note:
your first test with German VPN has higher ping, because the packets are forwarded from FR to GB.

NOTE:
I have an App(for windows) and I can ping the Server directly on port 19132.

 

[KLsz]

Using VPN: flow_data
Client -> VPN -> ISP -> Remote Server -> Cubecraft.
And
Cubecraft -> Remote Server -> ISP -> VPN -> Client.

Without VPN: flow_data
Client -> ISP -> Cubecraft.
Cubecraft -> ISP -> Client.

NOTE:
This is only for Bedrock.
Java is another story.
I'm not against VPN, players are free to use whatever they want.

I believe it is something like this:
With VPN: Applications on your Computer -(Raw Packet)-> VPN Client on your Computer -(Encrypted Packet)-[through your ISP, through all the other hops]-> VPN Server -(Raw Packet)-[through some more hops]-> CubeCraft. The return is through the exact process but reversed.
Without VPN: Applications on your Computer -(Raw Packet)-[through your ISP, through all the other hops]-> CubeCraft.

This flow of data I believe is unrelated to whatever program that is sending data through the VPN service. It doesn't matter if you are using the Minecraft, your browser or your social media apps. It also doesn't matter if you are using your desktop computer or mobile phone. It is always as such. The data gets encrypted on your own device, before they are sent to the VPN server. The VPN server decrypts your data and forwards it to your destination.
Please read Wikipedia: en.wikipedia.org/wiki/Virtual_private_network .

 

[AM71113363]

I believe it is something like this:
With VPN: Applications on your Computer -(Raw Packet)-> VPN Client on your Computer -(Encrypted Packet)-[through your ISP, through all the other hops]-> VPN Server -(Raw Packet)-[through some more hops]-> CubeCraft. The return is through the exact process but reversed.
Without VPN: Applications on your Computer -(Raw Packet)-[through your ISP, through all the other hops]-> CubeCraft.

With VPN are more hops than without, which mean higher ping.

This flow of data I believe is unrelated

I didnt say that is related.
It doesnt matter who sends the data MC/Browser, it matters only the shortest path from Client to Final Destination.

 

[KLsz]

using traceroute with/without VPN

Both of that two screenshots are captured while using a VPN service. My point on that two screenshots is to explain that you can connect to CubeCraft through different hops when you are connecting from a different location using a VPN service.

use the same IP instead of hostname

Yeah, It is my fault that I didn't notice that.

because the packets are forwarded from FR to GB

Ping doesn't matter in this particular part of problem.

 

[KLsz]

With VPN are more hops than without, which mean higher ping.


I didnt say that is related.
It doesnt matter who sends the data MC/Browser, it matters only the shortest path from Client to Final Destination.

Please read my whole thing before sending a reply.

The problems above are mostly this kind of situation. It is triggered by a unstable internet connection on a glitchy program.

I'm talking about the problems with a unstable internet connection.

These are problems cause by a high ping, which I will discuss in Part 2 of this document. It is expected to be ready before Sep 25 Sat.

I'm not talking about high ping.

it matters only the shortest path from Client to Final Destination.

And also, do connect to CubeCraft through continental Asia. Please enjoy your shortest path.

 

[AM71113363]

Both of that two screenshots are captured while using a VPN service. My point on that two screenshots is to explain that you can connect to CubeCraft through different hops when you are connecting from a different location using a VPN service.

Yeah, It is my fault that I didn't notice that.
View attachment 200266

Ping doesn't matter in this particular part of problem.

I Think the point here is using or not VPN, and not which VPN Server is faster.
NOTE:
1. CB has diff IP, is MINECRAFT that selects the CB IP, and not the VPN.
2. I dont think the VPN server is using ALL his network just for you, maybe now you have lower ping, maybe later higher!!!
3. the ports used by CB for gaming have higher priority than other ports(including traceroute).
ONLY if you ping the server on port 19132, you will get real values.

 

[KLsz]

I Think the point here is using or not VPN, and not which VPN Server is faster.

Sir, have I mentioned the name of any VPN service providers?

is MINECRAFT that selects the CB IP, and not the VPN.

It is the CubeCraft that select the IP, not your Minecraft.

I dont think the VPN server is using ALL his network just for you, maybe now you have lower ping, maybe later higher!!!

Yes, you are right. VPN service will get overloaded if too many people are using the service at the same time. That's the thing VPN service providers will try to avoid. Yes, some service providers won't bother do that, but there are also some providers that do it very well.

the ports used by CB for gaming have higher priority than other ports(including traceroute).
ONLY if you ping the server on port 19132, you will get real values.

Why the CubeCraft server will decide the priority based on what port you are using? And also do you know that port is a thing only to TCP/UDP packet but not to ICMP packet?

And also I've started two traceroute with half a second between then. Which one do you think is faster?

 

[AM71113363]

Sir, have I mentioned the name of any VPN service providers?

No, ofcourse not, but you're using two diff VPN Servers(Germany+ Singapore).

It is the CubeCraft that select the IP, not your Minecraft.

OK,if you think so.
I dont Agree, but I have my opinion and you have yours.

Why the CubeCraft server will decide the priority based on what port you are using?

if I request an webpage to cubecraft.net 4 times per seconds, after 2 minutes my conn will be blocked with error " to many requests"
BUT
I can do the same thing with CB: 19132 and my conn will never get blocked.

And also do you know that port is a thing only to TCP/UDP packet but not to ICMP packet?

Internet Control Message Protocol (ICMP)
used by ping & traceroute.

 

[KLsz]

No, ofcourse not, but you're using two diff VPN Servers(Germany+ Singapore).

I'm just trying to compare two different routes, me connecting through Germany and me connecting through Singapore.

my opinion

I somehow believe one is a fact but not an opinion.
Quoted from Wikipedia, A fact is an occurrence in the real world.

I can do the same thing with CB: 19132 and my conn will never get blocked.

Ehhh,, how can you request a webpage from port 19132 on play.cubecraft.net?
And also do you think a webpage can be transferred in a single packet?

Also about the blockage, do you know how Cloudflare works?

Do you know what is a protocal?
And also what does these three words „higher”, „level”, „protocol” means when they are used together?

Well, let me find out where you are getting these words from.

RFC792 (INTERNET CONTROL MESSAGE PROTOCOL)​

                                                          September 1981
RFC 792



Destination Unreachable Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address from the original datagram's data.

   ICMP Fields:

   Type

      3

   Code

      0 = net unreachable;

      1 = host unreachable;

      2 = protocol unreachable;

      3 = port unreachable;

      4 = fragmentation needed and DF set;

      5 = source route failed.

   Checksum

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.

   Internet Header + 64 bits of Data Datagram

      The internet header plus the first 64 bits of the original


[Page 4]                                                              


September 1981                                                        
RFC 792



      datagram's data.  This data is used by the host to match the
      message to the appropriate process.  If a higher level protocol
      uses port numbers, they are assumed to be in the first 64 data
      bits of the original datagram's data.

   Description

      If, according to the information in the gateway's routing tables,
      the network specified in the internet destination field of a
      datagram is unreachable, e.g., the distance to the network is
      infinity, the gateway may send a destination unreachable message
      to the internet source host of the datagram.  In addition, in some
      networks, the gateway may be able to determine if the internet
      destination host is unreachable.  Gateways in these networks may
      send destination unreachable messages to the source host when the
      destination host is unreachable.

      If, in the destination host, the IP module cannot deliver the
      datagram  because the indicated protocol module or process port is
      not active, the destination host may send a destination
      unreachable message to the source host.

      Another case is when a datagram must be fragmented to be forwarded
      by a gateway yet the Don't Fragment flag is on.  In this case the
      gateway must discard the datagram and may return a destination
      unreachable message.

      Codes 0, 1, 4, and 5 may be received from a gateway.  Codes 2 and
      3 may be received from a host.





















                                                                [Page 5]

                                                          September 1981
RFC 792



Time Exceeded Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address from the original datagram's data.

   ICMP Fields:

   Type

      11

   Code

      0 = time to live exceeded in transit;

      1 = fragment reassembly time exceeded.

   Checksum

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.

   Internet Header + 64 bits of Data Datagram

      The internet header plus the first 64 bits of the original
      datagram's data.  This data is used by the host to match the
      message to the appropriate process.  If a higher level protocol
      uses port numbers, they are assumed to be in the first 64 data
      bits of the original datagram's data.

   Description

      If the gateway processing a datagram finds the time to live field


[Page 6]

                                                          September 1981
RFC 792



Parameter Problem Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Pointer    |                   unused                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address from the original datagram's data.

   ICMP Fields:

   Type

      12

   Code

      0 = pointer indicates the error.

   Checksum

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.

   Pointer

      If code = 0, identifies the octet where an error was detected.

   Internet Header + 64 bits of Data Datagram

      The internet header plus the first 64 bits of the original
      datagram's data.  This data is used by the host to match the
      message to the appropriate process.  If a higher level protocol
      uses port numbers, they are assumed to be in the first 64 data
      bits of the original datagram's data.




[Page 8]

                                                          September 1981
RFC 792



Source Quench Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address of the original datagram's data.

   ICMP Fields:

   Type

      4

   Code

      0

   Checksum

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.

   Internet Header + 64 bits of Data Datagram

      The internet header plus the first 64 bits of the original
      datagram's data.  This data is used by the host to match the
      message to the appropriate process.  If a higher level protocol
      uses port numbers, they are assumed to be in the first 64 data
      bits of the original datagram's data.

   Description

      A gateway may discard internet datagrams if it does not have the
      buffer space needed to queue the datagrams for output to the next
      network on the route to the destination network.  If a gateway


[Page 10]

                                                          September 1981
RFC 792



Redirect Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Gateway Internet Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Destination Address

      The source network and address of the original datagram's data.

   ICMP Fields:

   Type

      5

   Code

      0 = Redirect datagrams for the Network.

      1 = Redirect datagrams for the Host.

      2 = Redirect datagrams for the Type of Service and Network.

      3 = Redirect datagrams for the Type of Service and Host.

   Checksum

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.

   Gateway Internet Address

      Address of the gateway to which traffic for the network specified
      in the internet destination network field of the original
      datagram's data should be sent.




[Page 12]                                                              


September 1981                                                        
RFC 792



   Internet Header + 64 bits of Data Datagram

      The internet header plus the first 64 bits of the original
      datagram's data.  This data is used by the host to match the
      message to the appropriate process.  If a higher level protocol
      uses port numbers, they are assumed to be in the first 64 data
      bits of the original datagram's data.

   Description

      The gateway sends a redirect message to a host in the following
      situation.  A gateway, G1, receives an internet datagram from a
      host on a network to which the gateway is attached.  The gateway,
      G1, checks its routing table and obtains the address of the next
      gateway, G2, on the route to the datagram's internet destination
      network, X.  If G2 and the host identified by the internet source
      address of the datagram are on the same network, a redirect
      message is sent to the host.  The redirect message advises the
      host to send its traffic for network X directly to gateway G2 as
      this is a shorter path to the destination.  The gateway forwards
      the original datagram's data to its internet destination.

      For datagrams with the IP source route options and the gateway
      address in the destination address field, a redirect message is
      not sent even if there is a better route to the ultimate
      destination than the next address in the source route.

      Codes 0, 1, 2, and 3 may be received from a gateway.






















                                                               [Page 13]

These are the five occurrences where that line of words is coming from.

I think I should also show some other pages of the document here, because you are not going to find it out by yourself.

RFC792 (INTERNET CONTROL MESSAGE PROTOCOL)​

Network Working Group                                          J. Postel
Request for Comments:  792                                           ISI
                                                          September 1981
Updates:  RFCs 777, 760
Updates:  IENs 109, 128

                   INTERNET CONTROL MESSAGE PROTOCOL

                         DARPA INTERNET PROGRAM
                         PROTOCOL SPECIFICATION



Introduction

   The Internet Protocol (IP) [1] is used for host-to-host datagram
   service in a system of interconnected networks called the
   Catenet [2].  The network connecting devices are called Gateways.
   These gateways communicate between themselves for control purposes
   via a Gateway to Gateway Protocol (GGP) [3,4].  Occasionally a
   gateway or destination host will communicate with a source host, for
   example, to report an error in datagram processing.  For such
   purposes this protocol, the Internet Control Message Protocol (ICMP),
   is used.  ICMP, uses the basic support of IP as if it were a higher
   level protocol, however, ICMP is actually an integral part of IP, and
   must be implemented by every IP module.

   ICMP messages are sent in several situations:  for example, when a
   datagram cannot reach its destination, when the gateway does not have
   the buffering capacity to forward a datagram, and when the gateway
   can direct the host to send traffic on a shorter route.

   The Internet Protocol is not designed to be absolutely reliable.  The
   purpose of these control messages is to provide feedback about
   problems in the communication environment, not to make IP reliable.
   There are still no guarantees that a datagram will be delivered or a
   control message will be returned.  Some datagrams may still be
   undelivered without any report of their loss.  The higher level
   protocols that use IP must implement their own reliability procedures
   if reliable communication is required.

   The ICMP messages typically report errors in the processing of
   datagrams.  To avoid the infinite regress of messages about messages
   etc., no ICMP messages are sent about ICMP messages.  Also ICMP
   messages are only sent about errors in handling fragment zero of
   fragemented datagrams.  (Fragment zero has the fragment offeset equal
   zero).







                                                                [Page 1]

                                                          September 1981
RFC 792



Message Formats

   ICMP messages are sent using the basic IP header.  The first octet of
   the data portion of the datagram is a ICMP type field; the value of
   this field determines the format of the remaining data.  Any field
   labeled "unused" is reserved for later extensions and must be zero
   when sent, but receivers should not use these fields (except to
   include them in the checksum).  Unless otherwise noted under the
   individual format descriptions, the values of the internet header
   fields are as follows:

   Version

      4

   IHL

      Internet header length in 32-bit words.

   Type of Service

      0

   Total Length

      Length of internet header and data in octets.

   Identification, Flags, Fragment Offset

      Used in fragmentation, see [1].

   Time to Live

      Time to live in seconds; as this field is decremented at each
      machine in which the datagram is processed, the value in this
      field should be at least as great as the number of gateways which
      this datagram will traverse.

   Protocol

      ICMP = 1

   Header Checksum

      The 16 bit one's complement of the one's complement sum of all 16
      bit words in the header.  For computing the checksum, the checksum
      field should be zero.  This checksum may be replaced in the
      future.


[Page 2]                                                              


September 1981                                                        
RFC 792



   Source Address

      The address of the gateway or host that composes the ICMP message.
      Unless otherwise noted, this can be any of a gateway's addresses.

   Destination Address

      The address of the gateway or host to which the message should be
      sent.









































                                                                [Page 3]

RFC791 (INTERNET PROTOCOL)​

September 1981                                                        
                                                       Internet Protocol



                           3.  SPECIFICATION

3.1.  Internet Header Format

  A summary of the contents of the internet header follows:

                                   
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Example Internet Datagram Header

                               Figure 4.

  Note that each tick mark represents one bit position.

  Version:  4 bits

    The Version field indicates the format of the internet header.  This
    document describes version 4.

  IHL:  4 bits

    Internet Header Length is the length of the internet header in 32
    bit words, and thus points to the beginning of the data.  Note that
    the minimum value for a correct header is 5.












                                                               [Page 11]

Quote from the first page, „Occasionally a gateway or destination host will communicate with a source host, for example, to report an error in datagram processing. For such purposes this protocol, the Internet Control Message Protocol (ICMP), is used.” Combined this with the words from those five occurrences, let me make an uneducated guess, that it means when the source host send some data to the destination host using a higher level protocol that have port numbers, and when the destination host decide to return with an ICMP message, either a Destination Unreachable Message, a Time Exceeded Message, a Parameter Problem Message, a Source Quench Message, or a Redirect Message, the destination host should include the port numbers at the first 64 data bits of the original datagram's data, which is right after the internet header, starting from the 257th bit of the ICMP message.
According to page 2, „ICMP messages are sent using the basic IP header”. And as you can see in the page 2 and 3 (of RFC792), as well as page 11 of RFC791, port numbers are not a part of internet header.

This means that although port numbers is included, if nessecary, in the data datagram, but it is not in the header, which means NO, you can not ping a specific TCP/UDP port using an ICMP packet.

Again, please read informations and understand what you are talking about before sending a reply to me. Thank you.

 

[AM71113363]

Q:
Do you know what is a protocal?
And also what does these three words „higher”, „level”, „protocol” means when they are used together?

A:
If you dont fully understand ICMP, than dont talk about it.

Q:
Ehhh,, how can you request a webpage from port 19132 on play.cubecraft.net?
And also do you think a webpage can be transferred in a single packet?
Also about the blockage, do you know how Cloudflare works?

A:
I didnt say that I'm using port 19132 to request a webpage. I used cubracraft.net as an example(I didnt want to write other hostnames).

NOTE:
I dont understand why you're trying to prove that I'm wrong.
You can write "I dont Agree" (like I did).
There is no point in commenting this thread with "What I know" & "What You Know".

JUST TO BE CLEAR
Before clicking "Join" to play CB, is Minecraft that selects the IP to ping, after clicking "Join" , is CB that connects you to NA or EU,
but,
at this point you cant change VPN Server without leaving the game.

 

[KLsz]

If you dont fully understand ICMP, than dont talk about it.

If RFC792 does not define ICMP, what defines?

Quote from the first page, „Occasionally a gateway or destination host will communicate with a source host, for example, to report an error in datagram processing. For such purposes this protocol, the Internet Control Message Protocol (ICMP), is used.” Combined this with the words from those five occurrences, let me make an uneducated guess, that it means when the source host send some data to the destination host using a higher level protocol that have port numbers, and when the destination host decide to return with an ICMP message, either a Destination Unreachable Message, a Time Exceeded Message, a Parameter Problem Message, a Source Quench Message, or a Redirect Message, the destination host should include the port numbers at the first 64 data bits of the original datagram's data, which is right after the internet header, starting from the 257th bit of the ICMP message.
According to page 2, „ICMP messages are sent using the basic IP header”. And as you can see in the page 2 and 3 (of RFC792), as well as page 11 of RFC791, port numbers are not a part of internet header.

This means that although port numbers is included, if nessecary, in the data datagram, but it is not in the header, which means NO, you can not ping a specific TCP/UDP port using an ICMP packet.

And also if you think you know more about ICMP than me, please point out my mistake specifically here. Don't just use meaningless talk to refute me, use proof.

In the end, do you have basic level of knowledge about computer programming?

I didnt say that I'm using port 19132 to request a webpage. I used cubracraft.net as an example(I didnt want to write other hostnames).

Is it the same of requesting a 64-byte empty TCP packet compared to a several-dozen-kilobyte webpage to say the HTML alone? LOL.

I dont understand why you're trying to prove that I'm wrong.

I don't know why you are insisting saying I'm wrong either. If you don't have the proof of saying I'm wrong, just don't say it.

You can write "I dont Agree" (like I did).

And also do you know what is a fact, and what is an opinion?
Do have have to tell you fundamental knowledge about philosophy?

There is no point in commenting this thread with "What I know" & "What You Know".

Heh, who said the sentence „If you dont fully understand ICMP, than dont talk about it.” just now???
And also if you want me to point out, do you remember what your first ever sentence in this thread is?

this submarine cable is a FIBER OPTIC CABLE
The data travels at speed of light.

^ I believe this is very much a „what I know” thing, isn't it? And now you are saying there is no point commenting with „what I know”? ROFL.

Before clicking "Join" to play CB, is Minecraft that selects the IP to ping, after clicking "Join" , is CB that connects you to NA or EU,

Do you know what is DNS? What is a DNS load balancing? :D
Can you please check out RFC1794 (DNS Support for Load Balancing) before saying this?
Do I really have to decompile Minecraft's source code to see if they are really using the first address provided by DNS servers and java.net.InetAddress?

Again, sir, can you please check out what you are speaking before you speak?

 

[AM71113363]

Ok, if you think that my commentes are pointless, you can ask to a MOD to delete them.
NOTE:
I've made this , you can use it if you want, is not a virus