Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Refactor CellMessageRoutingBuilder #436

Closed

Conversation

FunKuchen
Copy link
Contributor

Description

  • Refactored CellMessageRoutingBuilder to new standards
  • Every configurable aspect now has a seperate method in the builder
    • streaming(long streamDuration, long streamBandwidthInBitPs)
    • protocol(ProtocolType type)
      • tcp()
      • udp()
    • destination(NetworkAddress networkAddress)
      • destination(String receiverName)
      • destination(byte[] ipv4Address)
      • broadcast()
    • mbs()
    • topological()
    • geographical(GeoArea area)

What is this PR about?

Issue(s) related to this PR

  • Resolves part of internal issue 917

Affected parts of the online documentation

  • Changes in the communication documentation on the website are required
  • Addressed in internal issue 911

Definition of Done

Prerequisites

  • You have read CONTRIBUTING.md carefully.
  • You have signed the Contributor License Agreement.
  • Your GitHub user id is linked with your Eclipse Account.

Required

  • The title of this merge request follows the scheme type(scope): description (in the style of Conventional Commits)
  • You have assigned a suitable label to this pull request (e.g., enhancement, or bugfix)
  • origin/main has been merged into your Fork.
  • Coding guidelines have been followed (see CONTRIBUTING.md).
  • All checks on GitHub pass.
  • All tests on Jenkins pass.

Requested (can be enforced by maintainers)

  • New functionality is covered by unit tests or integration tests. Code coverage must not decrease.
  • If a bug has been fixed, a new unit test has been written (beforehand) to prove misbehavior
  • There are no new SpotBugs warnings.

Special notes to reviewer

FunKuchen and others added 29 commits June 19, 2024 14:39
…ipse#423)

* build: store etc-files in mosaic-starter and copy them to bundle and integration tests
* clean: remove unnecessary properties from copy-resources definition
* ci: use SUMO 1.21.0 for testing
* feat(sumo): support SUMO 1.21.0

Added hint, that SUMO_HOME/bin must be present in the PATH variable. Pre-loading some libraries is not required anymore then.
* refactor: don't use this whenever possible
… routing (eclipse#428)

* feat(sns): cleanup, minor performance improvement for flooding (early exit if flooding could not be progressed)
…nts (eclipse#420)

* feat: introducing SensorModule to provide access to environmental events
* feat(application): allow registration of callback for lidar sensor module
* feat(application): re-use Perceptive interface for accessing new sensor modules
return destination(new NetworkAddress(NetworkAddress.BROADCAST_ADDRESS));
}

public CellMessageRoutingBuilder mbs() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if I call broadcast().topological().mbs()?

I think you need to add Valitate.isTrue(routing != DestinationType.CELL_TOPOCAST, "MBS can only be activated for geographical routing.")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that would be correct. I also just saw the case where we call .destination(xy).mbs().build(). This would work, as all checks pass, but we would not have the geographical area for the mbs. This is only given if we also add .geographical(area) to the builder. Should we allow mbs to have an area parameter or should I check for this case separatley?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we allow mbs to have an area parameter or should I check for this case separatley?

You mean, if we should enforce it (you wrote "allow")? I think so. You can check that (and more?) in the checkNecessaryValues method at the end.

@kschrab kschrab closed this Nov 19, 2024
@FunKuchen FunKuchen deleted the 917-refactor-cell-message-routing branch November 19, 2024 10:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants