Home / Swift / Network

Swift implementation of RSocket Protocol

rsocket-swift is an implementation of the RSocket protocol in Swift.
Information
Category: Swift / Network
Watchers: 8
Star: 26
Fork: 3
Last update: Apr 4, 2021
Resource links
https://github.com/rsocket/rsocket-swift

rsocket-swift

rsocket-swift is an implementation of the RSocket protocol in Swift. It's an alpha version and still under active development. Do not use it in a production environment!

Strategy

In phase one, the plan is to focus on the client APIs along with support for the following features

Transport

  • WebSocket

Interaction Model

  • Request/Response

In the following phases, the plan is to implement the server APIs along with support for

  • All interaction models.
  • Leasing and flow control.

Dependencies

  • SwiftNIO - Async IO library on iOS
  • Combine - Reactive-streams implementation
  • Swift-concurrency - Concurrency support in Swift
0 Open More issues
Closed

adds initial frame parsing logic

Summary

This PR adds structs and en-/decoding logic required for serialisation of rSocket frames.

Details

~~First and foremost, the parsing logic uses Data as its essential binary representation, as Data is contained in Foundation (standard library in Swift) and other binary representations like ByteBuffer are convertible to it.~~

~~To make working with Data a bit safer and remove boilerplate, I added a dependency on a very lightweight library called BinaryKit. It is a very efficient wrapper around Data which makes it easier to, for example, append single bits to a binary. As it stands, we have created a PR to make parsing a bit more efficient for our use case. If our goal is to not have such a dependency, we could replicate something similar which is optimised for our use case, but I leave that up for debate, as it also would be more code to maintain.~~

Edit: This PR now uses ByteBuffer for its serialisation.

I have structured the frame parsing for each frame in the following parts:

Frame struct:

ErrorFrame.swift 
public struct ErrorFrame {
    public let header: FrameHeader

    public let errorCode: ErrorCode

    public let errorData: String

    public init(
        header: FrameHeader,
        errorCode: ErrorCode,
        errorData: String
    ) {
        self.header = header
        self.errorCode = errorCode
        self.errorData = errorData
    }
}

Decoder:

ErrorFrameDecoder.swift 
public struct ErrorFrameDecoder: FrameDecoder {
    public func decode(header: FrameHeader, buffer: inout ByteBuffer) throws -> ErrorFrame {
        guard let codeValue: UInt32 = buffer.readInteger() else {
            throw FrameError.tooSmall
        }
        let errorCode = ErrorCode(rawValue: codeValue)
        let errorData: String
        if buffer.readableBytes > 0 {
            guard let string = buffer.readString(length: buffer.readableBytes) else {
                throw FrameError.stringContainsInvalidCharacters
            }
            errorData = string
        } else {
            errorData = ""
        }
        return ErrorFrame(
            header: header,
            errorCode: errorCode,
            errorData: errorData
        )
    }
}

Encoder:

ErrorFrameEncoder.swift 
public struct ErrorFrameEncoder: FrameEncoder {
    public func encode(frame: ErrorFrame, using allocator: ByteBufferAllocator) throws -> ByteBuffer {
        var buffer = try FrameHeaderEncoder().encode(header: frame.header, using: allocator)
        buffer.writeInteger(frame.errorCode.rawValue)
        if !frame.errorData.isEmpty {
            let bytesWritten = buffer.writeString(frame.errorData)
            guard bytesWritten > 0 else {
                throw FrameError.stringContainsInvalidCharacters
            }
        }
        return buffer
    }
}

I chose to have separate encoders/decoders with instance methods instead of static ones for several reasons:

  • similar to JSONEncoder/JSONDecoder from Foundation
  • instance methods make it possible to make en-/decoders "configurable", similarly to JSON coding where you can define a dateEncodingStrategy to use when serialising Date instances (e.g. millisecondsSince1970, secondsSince1970, etc.)
  • you can inject the corresponding en-/decoder dependency for better testability (to be able to perform method swizzling of static methods you would need Objective-C which would decrease performance a lot)

Example

To parse a given frame you would first parse the leading 6 bytes as the header to know which frame to parse. Then, depending on the type, you can use the corresponding implementation of the FrameDecoder protocol:

var frameBuffer: ByteBuffer = // ...

let headerDecoder = FrameHeaderDecoder()
let frameHeader = try headerDecoder.decode(buffer: &frameBuffer)
switch frameHeader.type {
case .error:
    let frameDecoder = ErrorFrameDecoder()
    let frame = try frameDecoder.decode(header: frameHeader, buffer: &frameBuffer)
    try frame.validate() // optionally validate the frame
// other frame types ...
default: break
}

For now I have chosen to use the throws syntax, but I'm a bit unhappy about it, since this means any errors thrown are untyped (only constrained to Error). What do you think about changing the return type to Result<ErrorFrame, ErrorFrameError> instead? This means, the call site knows exactly which type of error that occurs and does not have to have those wildcard catchall error cases. I will leave that up for debate as well.

Another thing I want to discuss is frame validation. For now, the serialisation logic will not perform full validation (e.g. streamId has to be 0 for certain frames), but I added an extension function for every frame that might perform some validation. What are your thoughts on this?

Discussion

Here is a quick summary on those three talking points in this PR:

  • ~~BinaryKit vs. self made~~
  • Typed errors using Result<Value, Error> instead of throws
  • Frame validation
opened Dec 29, 2020 by nkristek 5
Closed

adds initial project structure

This PR shows my suggestion for a project structure which supports the multi library approach we talked about. As seen in the Package.swift file there are 3 libraries:

  • RSocketCore: Has no dependencies and contains only parsing logic. Maybe it needs SwiftNIO for ByteBuffer (depending on which path we want to take regarding Data vs. ByteBuffer)
  • RSocketCombine: Has a dependency on RSocketCore to access the parsing logic and implements Combine publishers
  • RSocketReactiveSwift: Has a dependency on RSocketCore to access the parsing logic and ReactiveSwift to implement it using SignalProducer

The example project is not part of this PR as we should focus on the main library first.

opened Dec 15, 2020 by nkristek 5
Closed

provides essential info on the project

opened Nov 13, 2020 by iychche 5
Closed

improves CI Testing

improve CI Testing

Motivation:

Make sure RSocket does work on iOS & Linux too.

Modifications:

  • build & run tests on Ubuntu
  • run tests on iOS
  • enable thread sanitizer for iOS & macOS
  • build in parallel
  • run tests in parallel (except performance tests)
  • use xcodebuild to build & run tests on macOS

Result:

Tests now run on iOS and Linux too and should be slightly faster because of parallel building and testing

Discussion

Thread Sanitizer on Linux

On Linux, the test fail with thread sanitizer enabled. Thread santizer support on linux is new for swift and I think there is still a bug in it. For Example, RequestResponseTerminationBehaviourTests.testRequesterSendsCancel fails but it just calls a pure function and does not mutate any state. I don't have a working linux environment to debug this issue further so I would just leave thread sanitizer disabled for now. It is still enabled on macOS.

Thread Sanitizer Error for RequestResponseTerminationBehaviourTests.testRequesterSendsCancel 
Test Suite 'Selected tests' started at 2021-03-18 18:21:43.116
584
Test Suite 'RequestResponseTerminationBehaviourTests' started at 2021-03-18 18:21:43.129
585
Test Case 'RequestResponseTerminationBehaviourTests.testRequesterSendsCancel' started at 2021-03-18 18:21:43.129
586
ThreadSanitizer:DEADLYSIGNAL
587
==2562==ERROR: ThreadSanitizer: SEGV on unknown address 0x07fda4cff260 (pc 0x55ff68f291a5 bp 0x7c0000000000 sp 0x7ffc48ae00b8 T2562)
588
==2562==The signal is caused by a WRITE memory access.
589
    #0 __tsan::MemoryAccess(__tsan::ThreadState*, unsigned long, unsigned long, int, bool, bool) /home/build-user/llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_atomic_clang_x86.h:81 (RSocketPackageTests.xctest+0x1071a5)
590
    #1 StoreShadow /home/build-user/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:613 (RSocketPackageTests.xctest+0x1071a5)
591
    #2 MemoryAccessImpl1 /home/build-user/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:701 (RSocketPackageTests.xctest+0x1071a5)
592
    #3 MemoryAccess /home/build-user/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:878 (RSocketPackageTests.xctest+0x1071a5)
593
    #4 __tsan::ExternalAccess(void*, void*, void*, void (*)(__tsan::ThreadState*, unsigned long, unsigned long, int)) /home/build-user/llvm-project/compiler-rt/lib/tsan/rtl/tsan_external.cpp:67 (RSocketPackageTests.xctest+0xa01dc)
594
    #5 $s16RSocketCoreTests035RequestResponseTerminationBehaviourC0C24testRequesterSendsCancelyyFSbyKXEfu_ /home/runner/work/rsocket-swift/rsocket-swift/<compiler-generated>:? (RSocketPackageTests.xctest+0x51dc27)
595
    #6 $s16RSocketCoreTests035RequestResponseTerminationBehaviourC0C24testRequesterSendsCancelyyFSbyKXEfu_TA TerminationBehaviourTests.swift.o:? (RSocketPackageTests.xctest+0x51dc97)
596
    #7 $s6XCTest13XCTAssertTrue__4file4lineySbyKXK_SSyXKs12StaticStringVSutF ??:? (libXCTest.so+0x3d8a5)
597
    #8 $s16RSocketCoreTests035RequestResponseTerminationBehaviourC0C24testRequesterSendsCancelyyF /home/runner/work/rsocket-swift/rsocket-swift/Tests/RSocketCoreTests/TerminationBehaviourTests.swift:27 (RSocketPackageTests.xctest+0x51dbbf)
598
    #9 $s16RSocketCoreTests035RequestResponseTerminationBehaviourC0C0a7PackageC0E05__allc2__defgC033_A8597678E06260891431B4EF4ED59470LLSaySS_yycACctGvpZfiyycACcfu_yycfu0_ /home/runner/work/rsocket-swift/rsocket-swift/.build/x86_64-unknown-linux-gnu/debug/RSocketPackageTestsTestlist.derived/RSocketCoreTests.swift:33 (RSocketPackageTests.xctest+0x526ccd)
599
    #10 $s16RSocketCoreTests035RequestResponseTerminationBehaviourC0C0a7PackageC0E05__allc2__defgC033_A8597678E06260891431B4EF4ED59470LLSaySS_yycACctGvpZfiyycACcfu_yycfu0_TA RSocketCoreTests.swift.o:? (RSocketPackageTests.xctest+0x52b9cd)
600
    #11 $sIeg_ytIegr_TR crtstuff.c:? (RSocketPackageTests.xctest+0x33d6b7)
601
    #12 $sIeg_ytIegr_TRTA.109 RSocketCoreTests.swift.o:? (RSocketPackageTests.xctest+0x52b98d)
602
    #13 $sytIegr_Ieg_TRTA XCTestCase.swift.o:? (libXCTest.so+0x37a20)
603
    #14 $s6XCTest4test33_3BE257A46ADB477C7BF2D39968B39F9DLLyyAA0A4CaseCKcyyKcxcAERbzlFyAEKcfU_TA XCTestCase.swift.o:? (libXCTest.so+0x37a8b)
604
    #15 $s6XCTest0A4CaseCs5Error_pIeggzo_ACytsAD_pIegnrzo_TRTA XCTestCase.swift.o:? (libXCTest.so+0x37a03)
605
    #16 $s6XCTest0A4CaseCyts5Error_pIegnrzo_ACsAD_pIeggzo_TRTA XCTestCaseSuite.swift.o:? (libXCTest.so+0x28576)
606
    #17 $s6XCTest0A4CaseC10invokeTestyyF ??:? (libXCTest.so+0x363b6)
607
    #18 $s6XCTest0A4CaseC7performyyAA0A3RunCF ??:? (libXCTest.so+0x36105)
608
    #19 $s6XCTestAAC3runyyF ??:? (libXCTest.so+0x39de5)
609
    #20 $s6XCTest0A5SuiteC7performyyAA0A3RunCF ??:? (libXCTest.so+0x3803f)
610
    #21 $s6XCTestAAC3runyyF ??:? (libXCTest.so+0x39de5)
611
    #22 $s6XCTest0A5SuiteC7performyyAA0A3RunCF ??:? (libXCTest.so+0x3803f)
612
    #23 $s6XCTestAAC3runyyF ??:? (libXCTest.so+0x39de5)
613
    #24 $s6XCTest7XCTMain_9argumentss5NeverOSayAA0A4CaseCm04testE5Class_SaySS_yAGKctG8allTeststG_SaySSGtF ??:? (libXCTest.so+0x34b19)
614
    #25 $s6XCTest7XCTMainys5NeverOSayAA0A4CaseCm04testD5Class_SaySS_yAFKctG8allTeststGF ??:? (libXCTest.so+0x34548)
615
    #26 main /home/runner/work/rsocket-swift/rsocket-swift/.build/x86_64-unknown-linux-gnu/debug/RSocketPackageTestsTestlist.derived/main.swift:8 (RSocketPackageTests.xctest+0x52c9f4)
616
    #27 __libc_start_main ??:? (libc.so.6+0x270b2)
617
    #28 _start ??:? (RSocketPackageTests.xctest+0x7cd5d)
618

619
ThreadSanitizer can not provide additional info.
620
SUMMARY: ThreadSanitizer: SEGV /home/build-user/llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_atomic_clang_x86.h:81 in atomic_store<__sanitizer::atomic_uint64_t>
621
==2562==ABORTING

xcodebuild vs. SwiftPM

  • xcodebuild is not available on Linux
  • SwiftPM does not yet support running tests on iOS. We need to use xcodebuild for that.
  • SwiftPM and xcodebuild do not share any caches and will refetch and rebuild all dependencies which should be avoided.
  • Performance Tests are tricky:
    • Both SwiftPM and xcodebuild do support a filter option which lets us run only a subset of the tests.
    • SwiftPM only builds test targets which are needed
    • xcodebuild builds everything (or tries to)
      • normal tests in debug mode are no problem
      • performance tests need to be build in release configuration. In release mode, @testable import is not supported but used in most tests targets and all but RSocketCorePerformanceTests fail to build

Because of the reasons above, I have decided to use xcodebuild to build & run tests for macOS & iOS but run performance tests using SwiftPM. On Linux there was really no choice but to use SwiftPM.

opened Mar 18, 2021 by dnadoba 4
Closed

Provides Initial Project Structure

This PR intends to create the basic folder structure to be used by the rSocket Swift Library. This is in no way a final structure and developers are welcome to provide feedback.

opened Dec 14, 2020 by sumit-nathany 3
Closed

Use ByteBuffer throughout RSocket

Replace all occurrences of Foundation.Data with NIOCore.ByteBuffer.

Motivation:

ByteBuffer is much more efficient than Data. We also convert a lot between Data andByteBuffer and in very inefficient ways (i.e. by coping). We should remove them all and delay conversation to Data to the very last moment or don't do one at all.

Modifications:

  • replace all occurrences ofFoundation.Data with NIOCore.ByteBuffer
  • remove import Foundation if possible
  • add new operator asData() to DecoderProtocol and EncoderProtocol to make it convenience to convert from/to Foundation.Data. This makes it also possible to convert to Data without making a copy by configuring the byteTransferStrategy to .noCopy.

Result:

More efficient and simpler implementation.

Future Directions

That was our biggest dependency on Foundation. We still use Foundation in a some of places:

  • in KeepaliveHandler to use the TimeInterval typealias to Double
  • in JSONDataDecoder/Encoder to use JSONDecoder/Encoder
  • and in the new asData() operator

Replacing TimeInterval with Double is trivial. The over two are a bit more challenging. I think we would need to create a separate module e.g. RSocketFoundationCompat like SwiftNIO does with its NIOFoundationCompat module. This could be combined in the future with cross-import overlays which would mean that RSocketFoundationCompat is implicitly imported if RSocketCore and Foundation are imported. AFAIK, this is currently behind a feature flag but already used but Apple.

opened Aug 25, 2021 by dnadoba 2
Open

Ayush yadav001/add dispose api

Added Dispose api for closing channel socket connection

Motivation:

Once we connect a socket channel connection successfully , we need an api to close the channel connection.

Modifications:

Added the channel reference in RSocketNIOChannel/ClientBootstrap.swift file. Added dispose() method to close channel in ClientBootstrap.swift file. Added testRsocketConnectionCloseSuccess() test in RSocketCoreTests/EndToEndTests.swift file.

Result:

We can now easily make request for closing connection.

opened May 19, 2022 by ayush-yadav001 0
Open

[doc] update README protocol link

Update README Protocol dead link

Motivation:

Better documentation for customers

Modifications:

Update Protocol hyper to link

Result:

Link will not be 404

opened Dec 21, 2021 by tfung1 0
Open

Question: client stability

Hi Guys, we want to start using this client in our iOS app.

we are seeing the docs says it's not production-ready yet. does it related to the client also? We are also waiting for auto-reconnect and routes features, do we have any estimation of when they will be implemented?

also, we are interested if there any company that uses any rsocket client on iOS in production?

Thank you in advance

opened May 15, 2021 by liskov 5
Open

async/await and AsyncSequence Prototype

Just noticed that SwiftNIO has basic support for async/await 🎉 The PR is not meant to be merged. Just a quick outlook into the future.

The internal implementation is really ugly but it works and the call site looks really nice:

let bootstrap = ClientBootstrap(
    config: ClientSetupConfig(
        timeBetweenKeepaliveFrames: 0,
        maxLifetime: 30_000,
        metadataEncodingMimeType: "message/x.rsocket.routing.v0",
        dataEncodingMimeType: "application/json"
    ),
    transport: WSTransport(),
    timeout: .seconds(30)
)
let client = try await bootstrap.connect(host: host, port: port, uri: uri)

let stream = client.requester.requestStream(payload: Payload(
    metadata: route("searchTweets"),
    data: Data(searchString.utf8)
))

for try await payload in stream.prefix(limit) {
    let json = try JSONSerialization.jsonObject(with: payload.data, options: [])
    let data = try JSONSerialization.data(withJSONObject: json, options: [.prettyPrinted])
    let string = String(decoding: data, as: UTF8.self)
    print(string)
}

Take a look at Sources/Examples/AsyncTwitterClient/main.swift if you want to see how async/await could look like for RSocket. The complete implementation is in Sources/RSocketAsync/AsyncAwait.swift.

If you want to play around with it, you need a download a snapshot from https://swift.org/download/#snapshots with the lates changes from the main branch. async/await is available since Swift 5.4 and AsyncSequence only in Swift 5.5. As even Swift 5.4 is not yet release, this is highly experimental.

opened Apr 2, 2021 by dnadoba 1
Open

Add unit tests for frames.

This PR includes unit test for the different frame type. It covers test cases for initialization, encoding, decoding and flag setting.

This will increase the code coverage from 0% to 64%.

Screen Shot 2021-01-28 at 6 16 41 PM
opened Jan 28, 2021 by AasthaGupta 3

Contents

    rsocket Java implementation of RSocket
    joshlong @Mario5Gray had a great idea - a Feign for RSocket. So, here it is.
    alexeyxo Google ProtocolBuffers for Apple Swift
    TencentOpen KNV(Key-N-Value) is a very fast protocol engine for manipulating protocol data without knowing the detail of its contents. KNV serves for 3 main purposes: 1, As a fast protocol engine, supporting 1M+ processes per second; 2, As a schema-free protocol inspecter/modifier for general-purpose network server; 3, As a protocol and data storage engine for general data storage server.
    mafintosh Base encodings for protocol-buffers
    nimiq Official JavaScript implementation of the Nimiq protocol
    sergdort Xcode 8 Source Code Extension will generate conformance to Swift Equatable protocol based on type and fields selection.
    KyoheiG3 Example of requesting Protocol Buffers and JSON with Swift. API is Swift or Go.
    elizabethsiegle A Swift implementation of 30-seconds-of-code: A curated collection of useful Swift 4 snippets that you can understand in 30 seconds or less.
    protocolbuffers Protocol Buffers - Google's data interchange format
    google A Git protocol parser written in Go.
    bandprotocol Monolithic repository of everything Band Protocol
    dylanmckay protocol — Custom TCP/UDP protocol definitions
    Covertness coap-rs Constrained Application Protocol(CoAP) Covertness/coap-rs — A Constrained Application Protocol(CoAP) library for Rust.
    Kitura Socket framework for Swift using the Swift Package Manager. Works on iOS, macOS, and Linux.
    SwiftDocOrg Generates documentation for Swift projects
    apple Language Server Protocol implementation for Swift and C-based languages
    PureSwift Cross-Platform, Protocol-Oriented Programming base library to complement the Swift Standard Library. (Pure Swift, Supports Linux)
    FreeRDP FreeRDP is a free remote desktop protocol library and clients
    yenom Bitcoin protocol toolkit for Swift
    JakeLin Swift Language Weather is an iOS weather app developed in Swift 4.
    Share this repo

    Related Repos


    Network
    5
    Swift async/await OAuth 2.0 HTTP request library.
    Colaski SwAuth SwAuth is an OAuth 2.0 HTTP request library written in Swift for iOS 15.0+, macOS 12.0+, watchOS 8.0+, and tvOS 15.0+. Features Requirements In
     
    Network
    3
    Advanced Networking Layer Using Alamofire with Unit Testing
    Ali-Fayed Advanced Swift Networking Layer Hi there, This is Advanced Networking Layer Using Alamofire with Unit Testing 👋 Networking Layer Features: Generic AP
     
    Network
    24
    Backward compatible async/await for URLSession!
    mochidev URLSessionBackport URLSessionBackport aims to make it possible to use URLSession's new async/await syntax on older OSs, namely iOS 13 or macOS 10.15 a
     
    Network
    47
    📡 Lightweight yet powerful HTTP Client for Swift ages - Declarative + Combine + Decodable...
    immobiliare RealHTTP RealHTTP is a lightweight yet powerful client-side HTTP library. Our goal is make an easy to use and effortless http client for Swift. Featur
     
    Network
    13
    DNS tunnel for iOS based off of Iodine
    osy Purple Haze A DNS tunnel client for iOS based on Iodine. A paid Apple Developer account is required to build because of the entitlements needed for Ne
     
    Network
    21
    gRPC implementation for Common Lisp
    qitab gRPC Client Library in Common Lisp Overview This package defines a gRPC client library for Common Lisp. It wraps gRPC core functions with CFFI calls a
     
    Network
    22
    Generic Network Layer created using Swift.
    Shubham0812 Generic Network Layer created using Swift.
     
    Network
    117
    A macOS application to test APIs with HTTP methods (Decluttered Postman)
    PraneetNeuro A macOS application to test APIs with HTTP methods (Decluttered Postman), built with SwiftUI.
     
    Network
    4.2k
    Pulse is a powerful logging system for Apple Platforms. Native. Built with SwiftUI.
    kean Network Inspector for Apple Platforms
     
    Network
    10
    Lightweight OAuth 2.0 Client with PKCE
    d-date Lightweight OAuth 2.0 Client with PKCE
     
    Network
    10
    iOS tweak companion for WebMessage client
    sgtaziz iOS tweak companion for WebMessage client.
     
    Network
    19
    DNS over TLS and DNS over HTTPS Configuration for iOS
    snbl DNS over TLS and DNS over HTTPS Configuration for iOS
     
    Network
    12
    VPN daemon utilized by nitoTV to deliver VPN access on tvOS
    lechium VPN daemon utilized by nitoTV to deliver VPN access on tvOS
     
    Network
    1.5k
    The Swift language implementation of gRPC.
    grpc It is intended for use with Apple's SwiftProtobuf support for Protocol Buffers. Both projects contain code generation plugins for protoc, Google's Protocol Buffer compiler, and both contain libraries of supporting code that is needed to build and run the generated code.
     
    Network
    67
    Log iOS network traffic without a proxy
    evilpenguin NetworkSniffer will log ALL traffic for any iOS application. This includes WKWebView and UIWebView.