Well-known Channels

Even though there are so many pages on the Wiki that are out-of-date or in a state of disrepair (it clearly needs more editors ;)/> ), I'd like to suggest a new page: "Well-known Channels".

In the real world, there is a list of "well-known" TCP ports that are commonly in use by network services (such as Telnet=23 and FTP=21). It allows developers to know which ports to consider off-limits when they assign ports for a new service. So now that we have modem channels in ComputerCraft, I think we should begin to keep track of what programs use what channels, to reduce the chance of crosstalk/glitches when many programs are run on the same network. It looks like many of the programs here ignore packets that don't match their expected pattern - which is good - but now that we're not locked into the Rednet API anymore, it also makes sense for services to run on different channels. Thoughts?

This has been brought up before. It's pretty much completely unnecessary. Pick a channel, protect your communications against other communications on the same channel. Remember that the rednet API is still in common usage (for good reason!) and that servers will regularly get computer IDs above one thousand. There's no need to attempt to create an inevitably badly maintained and inaccurate list of channels that a subset of the community programs use.

I think this is a good idea, but with a filter that gives another problem.

If a program is good, and gets used very much then there should be allowed to get it's own rednet channel. That's the filter, the problem is: how do you know if a program gets used very much?

However, with or without filter I do agree that this unnecessary. Just confirm with your 'companion' and send the stuff you want to send.

I don't think this is needed at all. Like Lyqyd said, if your program is dealt to only handle your messages then there is no need for "registered channels" if you want to avoid the GPS channel or the rednet broadcast channel then just make sure its not rednet.CHANNEL_BROADCAST or gps.CHANNEL_GPS.

Also, I'm waiting for a server to get to the point of having so many computers that the rednet api errors saying that the channel is out of range :P/>

Lyqyd, on 25 October 2013 - 09:04 PM said:

Remember that the rednet API is still in common usage (for good reason!) and that servers will regularly get computer IDs above one thousand.

I'm well aware that the Rednet API is still common, but I'm at a loss to think of a good reason! Could you clarify?

theoriginalbit, on 25 October 2013 - 10:24 PM said:

…if you want to avoid the GPS channel or the rednet broadcast channel then just make sure its not rednet.CHANNEL_BROADCAST or gps.CHANNEL_GPS.

But that's exactly my point. Why avoid the GPS channel but not avoid the Turtle Swarm Miner channel, the Battleship channel, the Print3D channel. There are 65000+ channels - I say, leave the first 5000 unassigned for Rednet, and let developers stake out some of the remaining 60000 if they choose.

sens, on 26 October 2013 - 05:01 AM said:

But that's exactly my point. Why avoid the GPS channel but not avoid the Turtle Swarm Miner channel, the Battleship channel, the Print3D channel. There are 65000+ channels - I say, leave the first 5000 unassigned for Rednet, and let developers stake out some of the remaining 60000 if they choose.

No one is going to read it. There is no point, n00bs will just use whatever channel they want, whats to stop people from using any channel they want, for example I could go and use the Swarm Miner's channel if I wanted to. Personally I always use random channels, and/or have the user running my program select the channel. Does that mean I have to reduce UX to make a hard coded channel which could run a higher risk of collisions?! I don't think this idea works at all, it just has no plausible use.

theoriginalbit, on 26 October 2013 - 05:15 AM said:

whats to stop people from using any channel they want

Nothing. The list would be simply a way to declare what channels your programs use by default.

theoriginalbit, on 26 October 2013 - 05:15 AM said:

… and/or have the user running my program select the channel. Does that mean I have to reduce UX to make a hard coded channel which could run a higher risk of collisions?!

If my original post wasn't clear, I'm referring to default channels only. For example, FTP by default uses TCP port 21, but there's nothing stopping me from setting up an FTP server on port 31 if I'm craving Baskin Robbins that day. If your program lets users choose the port - well done!

sens, on 26 October 2013 - 05:01 AM said:

Lyqyd, on 25 October 2013 - 09:04 PM said:

Remember that the rednet API is still in common usage (for good reason!) and that servers will regularly get computer IDs above one thousand.

I'm well aware that the Rednet API is still common, but I'm at a loss to think of a good reason! Could you clarify?

That would be because it is tremendously useful. If your program is a general information server, yeah, you might want to use a specific channel, like GPS does. If you want point-to-point communication between two specific computers, it makes a lot of sense to use rednet, since that's what it is designed for. It provides a useful abstraction to simplify point-to-point communications, as well as providing a common interface that could be overridden by code that adds routing, so that point-to-point communication could be transported seamlessly across multiple hops to the destination. The shunning of rednet as "not advanced enough" is idiotic and a step in the wrong direction.

The list would be useless. The list would not ever be complete or properly maintained and there's no reason to even really care about conflicts. If your software can't handle malformed packets, that's really just too bad. Pick a port number you like or use rednet, either one.

Lyqyd, on 26 October 2013 - 04:16 PM said:

It provides a useful abstraction to simplify point-to-point communications, as well as providing a common interface that could be overridden by code that adds routing, so that point-to-point communication could be transported seamlessly across multiple hops to the destination.

Okay, point taken. And, may I add, you did a nice job of that in LyqydNet.

Lyqyd, on 26 October 2013 - 04:16 PM said:

The shunning of rednet as "not advanced enough" is idiotic and a step in the wrong direction.

I don't see it as any more or less advanced as using the modem peripheral directly, as it's simply a wrapper. Debating one over the other wasn't the object of this thread. Anyway, judging by the response I've gotten so far, this "well-known channels" idea seems not right for the moment, and I'll probably focus on fixing the existing Wiki issues once I get my permissions.

sens, on 26 October 2013 - 04:42 PM said:

I don't see it as any more or less advanced as using the modem peripheral directly, as it's simply a wrapper.

I think that is exactly the point. It is a lower-level protocol.If you want to avoid collisions and stake out your own space, write your code in such away that it only responds to your communications, not to any rogue communications on the same channel. Minecraft (and ComputerCraft) are not intended to operate on enterprise-class security and networking principles. It may be fun to add features which approximate this (for coolness, education or whatnot), but it is not essential to the game.

The idea is sound, but it's gonna fail in practice. Most coders don't exactly spend a lot of time researching best practices, or worrying about interop issues. The few people who would bother checking such a list (let alone keeping it updated) would be quite unlikely to bump into eachother along 65536 channels anyway.