MeshNode¶

Spot·Actor 주제 목차 · 스펙 목차 · 이전: 02. Spot 메시징 · 다음: 04. Actor 모델

RouteMesh에 참여하는 MeshNode의 identity, object role, object를 배치할 수 있는 조건과 startup 순서를 정의한다.

1. MeshNode 개요¶

MeshNode는 다른 node와 물리적으로 연결되고 Channel membership을 제공한다. Actor와 Spot은 이 연결을 사용하지만 MeshNode RID를 자신의 logical identity로 사용하지 않는다. Framework는 Actor와 Spot의 전역 logical identity를 현재 owner가 존재하는 MeshNode의 route로 연결한다.

2. MeshNode가 가지는 identity와 설정¶

MeshNode 하나에는 다음 정보가 속한다.

항목	의미와 변경 가능 여부
`MeshName`(하나의 RouteMesh 물리 연결 그룹을 식별하는 이름)	어떤 물리 RouteMesh와, MeshNode가 RouteMesh의 automatic discovery에서 자신의 identity와 접속 정보를 알리기 위해 Location Store에 게시하는 등록 정보인 MeshNode descriptor namespace에 속하는지를 정한다. MeshNode가 시작된 뒤에는 바꿀 수 없다.
Routing ID(`RID`)	같은 RouteMesh 안에서 MeshNode를 식별하는 byte 값이며, 현재 MeshNode lifecycle을 식별하는 transport identity다.
Endpoint	다른 peer가 이 MeshNode의 ROUTER에 연결할 주소다.
`ChannelName`(message를 보낼 Channel 범위를 식별하는 이름) set	Server role로 참여하는 Channel 목록이다. 0개 이상 등록할 수 있으며 시작된 뒤에는 바꿀 수 없다.
Object role	`None`, `Client`, `Server` 중 하나다. Startup 전에 정한다.
Lifecycle generation	같은 logical server/listener가 재시작되었을 때 이전 실행과 현재 실행을 구분하는 값이며, 같은 transport identity에서 서로 다른 lifecycle을 구분하는 0이 아닌 식별 값이다.
Descriptor revision	같은 lifecycle 안에서 바뀔 수 있는 MeshNode descriptor 내용을 구분하는 0이 아닌 값이다.

MeshName은 ActorId나 SpotId의 identity에 포함되지 않는다. ActorId와 User·Instance SpotId는 Location Store가 관리하는 전체 transaction 범위에서 각각 전역 key다. MeshName은 object를 처음 배치할 Mesh와 현재 owner에게 도달할 물리 route를 나타내는 속성이다.

같은 process에는 같은 MeshName의 MeshNode를 하나만 등록할 수 있다. 서로 다른 MeshName의 MeshNode는 여러 개 등록할 수 있지만 Framework가 RouteMesh 사이의 transport relay를 자동으로 만들지는 않는다.

ChannelName을 추가해도 별도 socket이나 endpoint가 생기지 않는다. MeshNode descriptor를 공개한 뒤에는 다음 설정을 바꿀 수 없다.

Channel membership
Object role
등록된 stable type에 맞는 Spot instance를 생성하는 application 제공 코드인 Factory
Stable type과 type capability

3. Routing ID¶

3.1 Automatic RID¶

MeshNode automatic RID의 발급·형식·충돌·lifecycle 규칙은 Transport RID와 Spot ID 정책 §6이 정한다. Prefix를 생략하면 Framework는 listener 종류에 맞는 기본 prefix를 사용한다.

3.2 Entry Spot ID¶

Object Server MeshNode의 Entry Spot ID 발급·형식·충돌 규칙은 Transport RID와 Spot ID 정책 §6.3이 정한다.

Object Server MeshNode는 application이 Entry Spot type을 등록했는지와 무관하게 Entry Spot ID를 발급하고 descriptor에 싣는다. Entry Spot type 등록은 이 Spot이 실행할 application handler를 정할 뿐이며, descriptor의 entrySpotId 유무를 바꾸지 않는다. 원격 생성 요청을 받을 수 있는지도 이 등록으로 갈리지 않는다.

MeshNode descriptor의 Entry Spot ID mapping과 공개 규칙은 Transport RID와 Spot ID 정책 §6.3이 정한다.

Startup에서 Entry Spot을 준비하는 순서와 initialization이 끝나기 전 descriptor·resolver에 공개하지 않는 규칙은 §6이 정의한다.

3.3 Fixed RID¶

Fixed RID는 application이 MeshNode RID를 직접 정하는 설정이다. 구현·시험 시나리오가 peer를 이름으로 지목해야 할 때가 있고 automatic RID로는 그럴 수 없으므로, manual topology와 automatic discovery 모두에서, Object role과 관계없이 사용할 수 있다. Fixed RID와 automatic RID prefix를 함께 설정하면 startup configuration error다.

Fixed RID를 쓰는 node가 재시작해 이전 lifecycle의 active owner claim과 충돌하면 automatic RID와 같은 규칙으로 처리한다. 새 값을 만들어 다시 시도하지 않고 즉시 conflict로 startup이 실패하며, 이전 owner lease가 만료된 뒤 시작한 lifecycle은 같은 RID를 claim한다.

4. Object role과 등록할 수 있는 기능¶

MeshNode마다 object role을 최대 한 번 선택할 수 있다. 선택하지 않으면 None이다.

Object role	Logical object operation	Local factory와 Entry Spot	새 object를 배치할 target
`None`	Object operation을 제공하지 않는다.	만들지 않는다.	후보에서 제외한다.
`Client`	Object create, find와 message를 시작할 수 있다.	만들지 않는다.	후보에서 제외한다.
`Server`	`Client`가 제공하는 기능을 모두 포함한다.	등록한 type의 object와 Entry Spot을 실행한다.	등록한 type과 다른 placement 조건이 맞으면 후보가 된다.

Client와 Server role에는 Location Store가 필요하다. None을 선택하면 object manager, factory, placement 기능이나 숨겨진 local object runtime을 만들지 않는다. Factory와 Entry Spot은 Server builder에서만 등록할 수 있다. Entry Spot ID는 Framework가 발급하며 caller가 생성하거나 fixed RID를 지정할 수 없다.

Object Client는 Spot·Actor factory와, application이 MeshName과 target RID를 함께 지정해 특정 MeshNode로 message를 보내는 방식인 Node direct handler를 등록할 수 없다. Object 기능과 독립된 RouteMesh Channel Server는 같은 MeshNode에 등록할 수 있다. 이 조합은 object placement target이 아니지만 Channel target은 된다.

두 MeshNode가 모두 Object Client이고 양쪽 모두 RouteMesh Channel Server membership이 없을 때만 peer connection을 만들지 않는다. 어느 한쪽에 Server membership이 있으면 weight가 0이어도 연결한다. Channel Client membership만 있는 pair는 연결하지 않는다.

다음 .NET 발췌는 공통 role 선택과 factory 등록을 이해하기 위한 예시다. 다른 언어에 같은 signature를 요구하지 않으며, 정확한 .NET 계약은 .NET configuration interface가 정의한다.

public interface IZLinkMeshNodeBuilder
{
    IZLinkMeshNodeBuilder SetPlacementWeight(int weight);
    IZLinkMeshObjectRoleBuilder Objects(); // Object role 선택을 시작한다.
}

public interface IZLinkMeshObjectRoleBuilder
{
    IZLinkMeshObjectClientBuilder Client(); // Object operation만 시작할 수 있다.
    IZLinkMeshObjectServerBuilder Server(); // Factory와 Entry Spot도 등록할 수 있다.
}

public interface IZLinkMeshObjectServerBuilder
{
    IZLinkMeshObjectServerBuilder AddEntrySpot<TEntrySpot>()
        where TEntrySpot : class, IZLinkEntrySpot;
    IZLinkMeshObjectServerBuilder AddActorFactory<TActor, TFactory>(
        string actorType,
        Action<IZLinkActorFactoryBuilder<TActor>> configure)
        where TActor : class, IZLinkActor
        where TFactory : class, IZLinkActorFactory<TActor>;
}

public interface IZLinkActorFactoryBuilder<TActor>
    where TActor : class, IZLinkActor
{
    IZLinkActorFactoryBuilder<TActor> DisableRelocation();
    IZLinkActorFactoryBuilder<TActor> RecreateOnRelocation();
    IZLinkActorFactoryBuilder<TActor> PreserveStateWith<TAdapter>()
        where TAdapter : class, IZLinkActorRelocationAdapter<TActor>;
}

var mesh = options
    .AddRouteMesh("world")
    .SetPlacementWeight(100); // 새 object의 placement 선택에만 사용하는 weight다.

mesh.Objects()
    .Server()
    .AddActorFactory<PlayerActor, PlayerActorFactory>(
        "player",
        factory => factory.RecreateOnRelocation());
        // Stable type, factory와 relocation 방식을 한 등록에 함께 고정한다.

Actor, User Spot과 Instance Spot factory를 등록할 때는 다음 두 값을 반드시 함께 지정한다.

UTF-8 1..255 bytes의 stable type
DisableRelocation, RecreateOnRelocation, PreserveStateWith 중 하나의 relocation 방식

Framework는 factory 등록 호출 안에서 configure callback을 동기적으로 한 번 실행한다. Callback이 정상 반환하면 구성을 고정하며, 이후 보관해 둔 builder를 다시 호출하면 configuration error다. Callback이 예외를 던지면 해당 factory를 등록하지 않고 그 예외를 호출자에게 전달한다.

Stable type은 대소문자를 구분해 그대로 비교하는 값이다. Framework는 normalization을 적용하지 않으며 언어의 class 이름(namespace를 포함한 전체 이름)을 wire나 Store identity로 사용하지 않는다. 같은 (object kind, stable type) 조합을 두 번 등록하면 startup 오류다.

Relocation policy를 생략하는 overload나 compatibility default는 제공하지 않는다.

5. Object placement capability¶

Object Server의 MeshNode descriptor에는 node 전체에 적용할 placement weight, Actor·Spot capacity projection과 등록한 type별 capability가 포함된다.

5.1 Weight와 capacity¶

항목	계약
Placement weight	범위는 `0..10000`, 기본값은 `100`이다. Channel weight와는 별개다. 범위 밖 값은 startup 설정과 runtime 변경에서 configuration error다.
Node별 Actor limit	기본값 `0`은 제한 없음이다. 양수이면 `1..2^31-1` 범위의 최대 Actor 수다. 음수는 startup configuration error다.
Node별 Spot limit	기본값 `0`은 제한 없음이다. 양수 범위는 `1..2^31-1`이며 User Spot과 Instance Spot을 합산한다. 음수는 startup configuration error다.
Spot stable type별 limit	기본값 `0`은 제한 없음이다. 양수 범위는 `1..2^31-1`이며 해당 User·Instance Spot type에 적용한다. 음수는 startup configuration error다.
Entry Spot	Object Server node마다 하나로 고정하며 configurable Spot limit에서 제외한다.
Pending activation	기본값은 `128`이다. Target MeshNode는 자신이 진행 중인 activation 수가 이 limit 미만일 때 새 activation을 수락한다.

새 object를 만들거나 기존 object를 다른 node로 옮길 때는 Framework가 target MeshNode를 선택한다. Placement weight가 0인 MeshNode는 이 두 작업의 새 target 후보에서 제외한다.

이미 그 MeshNode에 존재하는 object로 보내는 message는 target을 새로 선택하는 작업이 아니므로 이 weight만으로 차단하지 않는다. Weight를 0으로 바꿔도 이미 확정된 reservation을 취소하지 않는다.

Framework는 Active count와 reserved slot을 합해 설정한 Actor·Spot limit을 먼저 검사하고 그 뒤에 weight를 적용한다. Limit 0은 검사를 생략한다. Capacity 조건을 만족하는 node가 하나도 없으면 Unavailable이다. Descriptor의 count는 후보 선택용 projection이며 Location Store의 atomic reservation이 최종 판정이다. 남은 후보의 positive placement weight 합계는 최소 64-bit 정수로 계산하여 넘치지 않게 한다.

Startup builder, runtime option, MeshNode descriptor와 monitoring snapshot은 같은 weight와 capacity 값을 사용한다.

5.2 Target node를 선택하는 조건¶

Logical create의 caller는 target RID, predicate 또는 placement callback을 지정하지 않는다. InMesh를 지정한 경우에도 target node가 아니라 후보를 찾을 Mesh만 선택한다.

Framework는 다음 조건을 사용해 target을 선택한다.

Node가 Serving 상태인지 확인한다.
Current owner lease가 유효한지 확인한다.
요청한 object kind와 stable type을 등록했는지 확인한다.
Active·pending capacity가 남아 있는지 확인한다.
남은 후보의 node-wide placement weight를 적용한다.

Framework는 선택한 node에 object를 배치할 자리를 예약하여 다른 생성 작업과 capacity를 중복 사용하지 않게 한다. Application에 target RID나 owner token을 선택하도록 요구하지 않는다.

GetOrCreate가 이미 Ready인 object를 찾았다면 current owner의 capacity와 weight를 다시 적용하지 않는다.

6. 등록과 startup 순서¶

Framework는 MeshNode를 다음 순서로 시작한다.

MeshName, object role, routing mode, endpoint, Channel set, factory, stable type, relocation policy, factory option과 capacity를 검증한다.
Location Store가 필요한 role이면 host owner lease를 확보하고 automatic RID의 MeshNode descriptor owner CAS를 완료한다. Object Server role이면 이 단계에서 Entry Spot ID를 발급하고 instance를 초기화한다. Initialization이 끝나기 전에는 descriptor와 resolver에 Entry Spot을 공개하지 않는다.
ROUTER를 bind한 뒤 다른 peer에 알릴 실제 endpoint를 확정한다.
필요한 정보를 모두 포함한 MeshNode descriptor를 공개하고 어떤 peer와 연결해야 하는지 계산한다.
연결한 remote node의 MeshName, RID, lifecycle, descriptor, object role과 security identity를 검사해 ready peer로 받아들일지 결정하는 과정인 Peer admission, local handler와 object runtime 준비를 마친 뒤 Serving 상태와 신규 target selection을 공개한다.

Object role을 사용하는 host는 Location Store를 명시적으로 등록해야 한다.

Manual mode에서는 application이 endpoint를 제공한다. Expected RID를 사용할 구성이라면 expected RID와 endpoint를 함께 제공한다. Manual mode는 object runtime을 제공하지 않는다.

7. Peer admission과 메시징¶

7.1 Peer 연결¶

Peer handshake에서는 다음 정보를 교환한다.

MeshName
RID
Lifecycle generation
Descriptor revision
변경할 수 없는 ChannelName set
Security identity

MeshName 또는 trust profile이 다르면 받아들이지 않는다. 같은 RID의 pipe가 둘 이상이면 Core가 하나를 선택하며(Core ROUTER §10.1), Framework는 선택된 route에서 받은 handshake만 admission한다.

Lifecycle generation은 0이 아닌 opaque equality token이다. 숫자 크기로 어느 lifecycle이 더 새로운지 판단하지 않는다.

Fixed RID로 다시 연결할 때는 다음 조건을 모두 만족한 뒤 다른 generation의 connection을 target selection에 포함한다.

Application 구성에 해당 peer와 연결하려는 의도가 있다.
인증된 connection handover를 완료했다.
Core의 선택 route가 새 route generation으로 바뀌었다.

Automatic RouteMesh에서는 RID가 더 작은 MeshNode만 connect를 시작한다. Manual 양방향 connect 또는 automatic 연결 경합으로 중복 후보가 생기면 RouteMesh의 중복 peer 연결 규칙에 따라 ready connection 하나만 유지한다.

특정 peer와 연결을 유지하려는 의도는 application 구성이나 auto-connect 소유자가 peer마다 하나씩 등록하는 connection intent로 표현한다. Runtime은 intent가 있는 동안만 connect와 재연결을 시도한다.

Outbound intent를 제거하면 같은 결정으로 그 endpoint의 binding 연결 등록도 제거한다. Intent 소유자가 binding의 public disconnect를 호출한다. 같은 endpoint에 inbound peer가 있어도 그 peer는 outbound 등록의 소유자가 아니므로 disconnect를 생략할 근거가 아니다 — 옛 등록이 남으면 새 RID로 다시 connect한 Hello가 옛 등록에 묶여 상대에 도달하지 않는다. Endpoint 교체 여부는 한 곳에서만 판정한다.
제거된 intent는 terminal이다. 같은 endpoint·RID의 늦은 READY는 이전 attempt의 잔여 관찰이지 새 연결 의도가 아니므로, 제거된 intent를 다시 활성화하지 않고 새 intent만 활성화한다. 이를 위한 별도 generation이나 상태는 두지 않는다.
Intent 제거와 admitted peer 부재가 함께 성립한 상태가 그 peer의 lifecycle 종료다. Transport 단절이나 peer 부재 단독은 재연결로 회복될 수 있는 transient 상태다. 이 사실을 durable operation이 어떻게 소비하는지는 Actor 모델 §8.1이 정한다.
Binding이 connect를 거절하면 그 attempt만 실패하고 intent는 남는다. Intent 소유자는 binding의 typed 오류를 runtime 오류 보고 경로에 그대로 남기고, 같은 intent의 다음 reconcile에서 connect를 다시 호출한다. 거절은 그 intent를 제거하지 않으며 다른 peer의 discovery나 host lifecycle을 끝내지 않는다. 거절을 성공 여부 값으로 바꾸어 원인을 지우지 않는다.

다음 그림은 물리 connection이 성립되는 순서를 보여준다 — handshake로 교환한 identity가 admission 판단을 통과해야 physical pipe가 ready 상태가 된다. Application이 지정하는 논리 target(ChannelName, ActorId, SpotId)이 이 physical pipe를 사용하는 방법은 §7.3이 정의한다 — 이 그림은 그 아래에 있는 물리 층만 그린다.

%%{init: {'sequence': {'actorFontSize': '18px', 'messageFontSize': '18px', 'noteFontSize': '18px', 'boxMargin': 8, 'width': 140}, 'themeVariables': {'fontSize': '18px'}}}%%
sequenceDiagram
    participant A as MeshNode A (작은 RID)
    participant B as MeshNode B (큰 RID)

    Note over A,B: 물리 connection 층 — ChannelName·ActorId·SpotId 같은<br/>논리 target 선택은 이 connection 위에서 별도로 이뤄진다
    A->>B: connect 시작 (automatic이면 RID가 작은 쪽만 시작)
    A->>B: handshake: MeshName, RID, lifecycle generation,<br/>descriptor revision, ChannelName set, security identity
    B->>B: Core가 선택한 route의 handshake에서 MeshName·trust profile 일치 확인
    alt admission 거부 조건에 해당
        B-->>A: admission 거부
    else 신규 lifecycle이거나 manual 재연결 3조건 충족
        B-->>A: admission 수락
        Note over A,B: 이 pipe가 ready 상태가 된다
        Note over A,B: 같은 RID의 pipe가 둘이면 Core가 하나를 선택하고, Framework는 선택 route에서만 admission한다
    end

7.2 Channel weight 갱신¶

Handshake는 Channel별 weight도 전달한다. Channel weight를 실행 중에 바꾸면 lifecycle generation은 유지하고 descriptor revision만 증가한다.

Peer는 현재 generation에서 더 큰 revision이 붙은 전체 weight snapshot만 적용한다. Weight 변경은 connection을 다시 만들거나 application message를 다시 적용하지 않으며, node-wide placement weight도 바꾸지 않는다.

7.3 메시징 방식별 target 선택¶

메시징 방식	Target을 선택하고 전달하는 방법
Node direct	Caller가 지정한 `MeshName` 안에서 특정 target RID로 한 번 제출한다. Object Client RID는 application Node direct target이 아니다.
Channel	Process-local `ChannelName` index로 RouteMesh를 찾고 Channel messaging §3에 따라 target을 선택한다.
Logical Multicast(ChannelName과 topic으로 같은 Channel의 여러 Spot에 message 하나를 전달하는 방식)	먼저 해당 ChannelName에 참여하고 ready 상태이며 Channel weight가 0보다 큰 remote MeshNode를 모두 선택한다. 각 수신 MeshNode는 자신의 local Spot 중에서 ChannelName과 topic 조건이 일치하는 subscription에 message를 전달한다.
Actor direct	Global ActorId의 current Ready authority를 확인한 뒤 current owner route로 제출한다.
Spot direct(global Spot ID 하나를 지정해 그 Spot에 send/request를 보내는 방식)	Global SpotId의 current Ready authority를 확인한 뒤 current owner route로 제출한다.

Actor·Spot direct는 logical ID만 target으로 사용한다. 같은 ActorId/Spot ID의 서로 다른 logical incarnation을 구분하는 번호인 ObjectGeneration을 어디에 사용하고 어디에 사용하지 않는지는 Routing §2.5가 정한다.

ChannelName의 target 선택과 message submit 경계는 Channel messaging §3이 정한다.

Node·Channel·Actor·Spot send와 request는 같은 MeshNode ROUTER를 사용한다. Classic fanout은 별도의 PUB/SUB socket 계약이며 MeshNode membership에 포함하지 않는다.

Node direct는 지정한 MeshName과 RID가 operation 의미에 포함되는 infrastructure, 진단 또는 manual topology에 사용한다. 여러 node가 같은 기능을 제공하는 application request에는 ChannelName을 사용한다.

Actor와 Spot 메시징은 global ActorId 또는 SpotId를 target으로 사용한다. Caller는 NodeRid나 MeshName을 target으로 넘기지 않는다.

기존 Actor·Spot의 current MeshName과 NodeRid는 Location Store authority가 제공한다. Missing Instance Spot에서만 Spot direct fluent call의 Instance intent에 optional initial Mesh와 stable type을 지정할 수 있다. Initial Mesh는 cold activation placement에만 사용하며 기존 owner의 현재 Mesh를 제한하거나 이동시키지 않는다.

Application payload는 실행 객체의 application turn에서 처리한다. Service-wire control과 Core completion의 수신 경계는 Application job queue §3, binding completion과의 합성은 같은 문서 §7을 따른다. Location reconcile과 reservation 같은 Framework 내부 작업도 application handler가 대기 중이어도 진행한다. Actor·Spot lifecycle application callback은 application turn에서 실행한다. Transport readiness callback에서 application handler를 직접 실행하지 않는다.

ChannelName handler와 RID direct handler는 서로 다른 namespace를 사용한다.

Channel handler context는 ChannelName과 reply source identity를 내부에 보존한다. 업무 코드에 MeshName이나 물리 route 선택을 노출하지 않는다.
RID direct handler context는 direct route의 MeshName과 source RID를 제공한다.

Spot Logical Multicast는 (ChannelName, topic filter) subscription을 node-local로 검사한다. 송신 MeshNode는 target Channel의 remote node마다 routed message를 한 번 제출한다. 수신 MeshNode는 일치하는 local Spot마다 같은 immutable message storage의 reference를 확보하여 Spot queue에 넣는다.

8. Drain과 종료¶

신규 작업의 target 선택과 admission은 Host relocation §14·§15를 따른다.

아직 relocation permit을 얻지 못한 unit의 existing owner message와 timer는 계속 처리한다. 모든 unit이 source dispatch에서 분리되면 host는 Relocated가 된다. Draining은 Shutdown이 admission을 닫을 때만 진입하며, 두 상태의 전이는 Host relocation §3이 소유한다.

이미 reservation을 끝낸 create, accepted message, completion과 relocation barrier는 정해진 deadline과 fence에 따라 terminal 상태까지 진행한다. 전체 종료와 handoff 순서는 Host relocation와 shutdown이 정의한다.

Runtime이 종료를 진행 중이어서 새 operation admission을 받을 수 없는 상태인 Shutdown은 새 relocation을 시작하지 않는다. Relocate는 등록한 relocation policy에 따라 Actor, User Spot aggregate와 Instance Spot을 이전한다.

Node weight를 0으로 바꾸거나 drain을 시작했다는 이유로 기존 object를 숨겨 다시 만들거나 application payload를 다른 owner에게 새 operation으로 제출하지 않는다.

9. 관측 정보¶

Runtime snapshot과 event는 다음 정보를 제공한다.

MeshName, RID, lifecycle generation과 endpoint
Object role과 node-wide placement weight
Active·pending·maximum capacity
Type capability와 reservation failure
Drain state

RID와 endpoint는 진단 정보로만 사용하며 metric label로 사용하지 않는다. 세부 계약은 Runtime 상태와 운영 진단이 정의한다.

10. 검증 요구¶

구현과 contract test는 공개 표면(MeshNode builder, startup 결과, MeshNode descriptor, runtime snapshot과 event)만으로 다음을 확인한다.

같은 process의 중복 MeshName과 잘못된 object role 구성이 startup에서 실패한다.
None, Client, Server가 manager, factory와 placement capability를 계약대로 제한한다.
Object role을 선택하지 않은 MeshNode는 None으로 시작하며 object manager, factory, Entry Spot과 placement capability를 만들지 않는다.
Object role과 Location Store의 잘못된 조합, fixed RID와 automatic RID prefix의 동시 설정이 startup에서 실패한다.
Automatic RID가 prefix와 lowercase canonical UUID v4 형식을 따르고 active conflict에서 두 번째 claim 없이 startup configuration error로 실패한다.
Automatic RID를 쓰는 replacement lifecycle이 새 RID를 사용한다.
Entry Spot type을 등록하지 않은 Object Server node의 descriptor에도 entrySpotId가 있고, Server가 아닌 node의 descriptor에는 없다.
Entry Spot ID가 MeshNode와 같은 diagnostic prefix, 별도로 생성한 UUID v4를 사용하며 descriptor가 lifecycle mapping을 공개한다.
Replacement lifecycle이 새 Entry Spot ID를 발급하고 Entry Spot authority 충돌에서 즉시 실패한다.
Stable type 중복과 relocation policy 생략이 startup에서 실패한다.
Placement weight는 0, 기본값 100과 상한 10000을 허용하고 -1과 10001은 startup 설정과 runtime 변경에서 거부한다.
Capacity가 weight보다 먼저 적용되고 weight 0이 existing object와 accepted reservation을 취소하지 않는다.
Channel weight 변경이 placement weight를 바꾸지 않는다.
Channel select-one이 Channel weight와 drain을 반영하고 Node direct에는 영향을 주지 않는다.
Logical Multicast가 remote node마다 한 번 전송되고 node-local Spot queue가 immutable storage를 공유한다.
ChannelName handler와 RID direct handler의 namespace 및 context가 구분된다.
Draining node가 새 placement target이 되지 않고 accepted operation은 terminal 상태까지 진행한다.
Actor·Spot application 호출이 NodeRid나 owner token을 target으로 요구하지 않는다.
두 MeshNode의 Application Job Queue가 모두 PAUSED여도 이미 시작한 cross-node request reply는 ROUTER-ROUTER Completion connection으로 진행해 timeout 전에 terminal completion을 만들 수 있다.
RouteMesh connection monitor는 logical peer마다 CONNECTION_READY를 한 번 보고하며 Completion physical event만 Completion lane 값을 사용한다.
같은 endpoint에 inbound peer가 admitted된 상태에서 outbound intent를 제거한 뒤 새 RID로 같은 endpoint에 다시 connect하면, 상대 node가 새 RID의 Hello를 받아 admission을 완료한다.
Intent를 제거한 peer의 endpoint·RID로 늦은 READY가 도착해도 그 peer가 다시 admitted 상태로 보고되지 않는다.

Spot·Actor 주제 목차 · 스펙 목차 · 이전: 02. Spot 메시징 · 다음: 04. Actor 모델