What's a "raw socket" in ktor? <https://ktor.io/d...

# ktor

[Colton Idle]

What's a "raw socket" in ktor?

https://ktor.io/docs/servers-raw-sockets.html#server_create_socket

I feel like it's a dumb question, because its probably me not understanding something fundamental in networking, but i essentially have two android devices on a local network, and i have them talking to each other via raw sockets in ktor. and while cool. i kinda dont understand whats going on. they can talk via raw sockets over udp or tcp, but technically dont things need to be application level (like http) to talk to each other?

[Casey Brooks]

HTTP is a protocol built on top of TCP. Essentially, it is just a "application level" or "layer 7" specification. The HTTP spec is most just a specific format of text sent over a socket which allows server and client applications to understand each other.

But HTTP isn't the only way to communicate at the application level. There are other "layer 7 protocols" you could use instead of HTTP, like FTP, Telnet, SMTP, etc. These protocols are much less common, so you don't always see them natively implemented in networking libraries like KTOR. You can use raw sockets to implement these protocols (or create your own if you need) by processing every byte that comes and goes through the socket individually.

These protocols are considered "application level" specifications because they really don't do anything specific with networking other than use a network. The specification itself is mostly just a text format, most useful by end-user applications. Dropping down a layer for something like SSH involves close interaction with the OS as part of the protocol, unlike HTTP or other formats.

[Casey Brooks]

So when you have 2 Android apps talking over a raw socket, you're basically just stating that you want to define what kind of data they work with, with every byte. You probably don't need this because you can do the exact same thing with HTTP without having to deal with validating and parsing message formats.

Realistically, you shouldn't need to use a TCP raw socket unless you are implementing a protocol that's not supported natively; it's not worth it to create your own protocol (unless it's just for education). Using a raw socket for UDP might be necessary for high-performance applications like multiplayer video games.

[Colton Idle]

I basically (for personal education) am creating a two person game. and basically just need to send very few bits of data (a few strings) back and forth. but yeah, I considered essentially having one device be an http server, because even with raw sockets I still need one person to be the server and the other be the client.

thanks for the breakdown. for whatever reason. i guess it didn't really click that http is just a raw socket with a sepcific spec, but i suppose that everything above tcp and udp is technically a raw socket with some sort of protocol/concrete implementation on top.

[rocketraman]

The other approach you can consider for your use case is something like rsocket, which provides an application protocol with support for common semantics (fire-and-forget, request/response, request/stream, or channel), where you define your own messages. See their motivations doc (https://rsocket.io/about/motivations) to understand why you may want to use it instead of HTTP. You could also consider a protocol built on top of HTTP such gRPC that provides some of those semantics, but since you probably want bidirectional communication HTTP/x is not ideal. You'd still choose it if you want to ensure network reachability, as outbound HTTP is almost never blocked.

[rocketraman]

Also, if you want to learn more about this topic, install wireshark and inspect some network packets flowing to and from an application you've built.

[Casey Brooks]

Websockets are another options, that can be nice to work with since most HTTP clients also support websockets. Browser devtools also let you inspect websocket traffic similar to how you’d inspect regular HTTP traffic. Websockets essentially give you the same kind of behavior you’d get from a KTOR raw socket, but they’re technically built on top of HTTP.

[rocketraman]

@Casey Brooks I wouldn't say websockets are technically built on top of HTTP. You can upgrade an HTTP connection to a websocket so communication runs over the same port, but websocket is an independent protocol that only provides framing. One still needs to implement an application protocol on top of it. That's where something like rsocket comes into play.

[Casey Brooks]

As a architectural tip, when creating a multiplayer game, what you’d probably want to do is have a separate server which manages the game state. You could technically have one of the client apps host this server, or it could live on its own hardware, in the cloud, etc.

Then both apps connect to the server and communicate with it, rather than directly communicating with each other. They send changes to the server, the server processes the changes, then it sends the updated game state to each client.

The alternative is basically having each client update its own copy of the game state, and you need to try and synchronize changes between the two clients. This can be tricky to get right, especially in the situation where the network is flaky and communication gets dropped, or when trying to scale up to more players. With a true client-server model, each client can request the latest game state if it ever has an issue with the network, and more players just means more apps connecting to the server.

[rocketraman]

With that architecture, you can also KISS for a toy game and use SSE to send updates from the server to each client.

[Colton Idle]

in my case im trying to build something where you could play in case the internet goes out, but you still have WAN. so i basically built something that can do mdns/multicast/dns service discovery (all of those seem to be the same thing) and now i have the two phones talking to each other, but now my last step is to just send json back and forth. 😄

[Colton Idle]

thanks for teaching. i learned a lot from everyone in this thread!