Source code
package io.netty.example.sctp;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelOption;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.MultiThreadIoEventLoopGroup;
import io.netty.channel.nio.NioIoHandler;
import io.netty.channel.sctp.SctpChannel;
import io.netty.channel.sctp.nio.NioSctpServerChannel;
import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler;
/**
* Echoes back any received data from a SCTP client.
*/
public final class SctpEchoServer {
static final int PORT = Integer.parseInt(System.getProperty("port", "8007"));
public static void main(String[] args) throws Exception {
// Configure the server.
EventLoopGroup group = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
final SctpEchoServerHandler serverHandler = new SctpEchoServerHandler();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(group)
.channel(NioSctpServerChannel.class)
.option(ChannelOption.SO_BACKLOG, 100)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SctpChannel>() {
@Override
public void initChannel(SctpChannel ch) throws Exception {
{
int firstScore = 72;
int secondScore = 85;
int higherScore;
if (firstScore > secondScore) {
higherScore = firstScore;
} else {
higherScore = secondScore;
}
}
ch.pipeline().addLast(
//new LoggingHandler(LogLevel.INFO),
serverHandler);
}
});
// Start the server.
ChannelFuture f = b.bind(PORT).sync();
// Wait until the server socket is closed.
f.channel().closeFuture().sync();
} finally {
// Shut down all event loops to terminate all threads.
group.shutdownGracefully();
}
}
}
Run 1
The code is structured as a typical Netty server bootstrap but contains a severe flaw: an unrelated block of code (comparing two integer scores) is randomly inserted inside the `initChannel` method before the actual pipeline setup. This completely breaks the logical organization and clarity of intent, making the code extremely confusing. Nesting is otherwise reasonable, but the erroneous block adds unnecessary nesting and ambiguity. Code length is acceptable for a Netty example, but the stray code makes it seem unnecessarily long. Action granularity is mostly one action per line, which is good. Reading flow is natural at the top (imports, Javadoc, constants) but is abruptly disrupted by the unrelated score-comparison logic, destroying the overall readability.
Run 2
The code generally follows good structure with clear comments and method chaining, but contains a serious readability flaw: an unrelated block of code (comparing firstScore and secondScore) is inexplicably inserted inside the initChannel method. This breaks the reading flow and confuses the intent. The nested anonymous inner class and if-else add unnecessary depth. Action granularity is mostly one action per line, and imports/logging are reasonable. However, the distracting dead code and misplacement significantly reduce clarity. Without that block, the score would be higher (around 16-17).
Run 3
The code is highly unreadable due to a glaring structural defect: a random, unrelated block of code (`int firstScore = 72; ...`) has been inserted inside the `initChannel` method, completely breaking the logical flow and purpose of the SCTP server example. This destroys code structure, clarity of intent, and reading flow. While the Netty boilerplate itself is reasonably concise and flat, the foreign block introduces unnecessary complexity and redundant logic. Action granularity is mostly one action per line, but the nested anonymous class plus the inserted block creates confusing nesting. Overall, the file appears corrupted or tampered with, making it impossible to follow the intended echo server implementation. Without the inserted block, the code would be moderately readable, but as presented it fails almost every criterion for readability.
Run 1
Code Structure: The server follows a logical setup, bind, wait, and cleanup sequence, but an unrelated score-comparison block interrupts channel initialization. Nesting: Mostly moderate, although the anonymous initializer, extra block, and if/else add unnecessary depth. Clarity of intent: The class documentation and lifecycle comments clearly explain the echo server; the unused higherScore calculation has no apparent purpose, and names like b and f are vague. Code length: Generally concise, but the irrelevant calculation and commented-out logging statement add clutter. Action granularity: Statements mostly perform one action per line, and the fluent configuration chain is easy to scan. Reading flow: The lifecycle reads naturally, but inconsistent indentation and the abruptly inserted comparison block significantly disrupt it.
Run 2
Code Structure: Server setup, startup, waiting, and cleanup are logically organized, but an unrelated score-comparison block interrupts channel initialization. Nesting: The try/finally, anonymous initializer, extra block, and conditional create moderately deep nesting. Clarity of intent: The echo-server purpose and lifecycle are clear, but unused score variables and generic names such as b and f weaken clarity. Code length: The server configuration is compact, but the irrelevant comparison and commented-out logging add unnecessary content. Action granularity: Statements generally perform one action per line, and the fluent configuration is split into readable steps. Reading flow: Lifecycle comments and consistent configuration ordering help, but the abruptly inserted, poorly indented comparison block substantially disrupts the flow.
Run 3
Code Structure: Server configuration, startup, waiting, and cleanup are logically organized, but an unrelated score-comparison block disrupts the channel initializer. Nesting: The try/finally, anonymous initializer, extra block, and conditional create moderately deep nesting. Clarity of intent: The echo-server purpose and lifecycle are clear, while unused score variables and the commented-out logging handler introduce distractions. Code length: Most setup is concise, but the irrelevant comparison adds unnecessary lines. Action granularity: Statements generally perform one action per line, and the fluent configuration chain is reasonably formatted. Reading flow: The lifecycle reads naturally overall, but the abruptly inserted, inconsistently indented block interrupts it; abbreviated names such as b, f, and ch also slightly reduce clarity.