Laden...

Forenbeiträge von ClaraSoft Ingesamt 55 Beiträge

13.01.2021 - 13:35 Uhr

Hallo T-Virus

Danke für dein Feedback. Du hast bei einigen Punkten Recht da besteht Verbesserungsbedarf, keine Frage. Ich gucke mal was ich wie Umsetze, besonders was Error Handling und das Parsen angeht.

Der Urprünglich von mir angedachte Einsatz Zweck war für TCP/UDP. Meine Aussage war eher als Anregung zu verstehen. Der User kann doch bisweilen sehr Kreativ werden. 😁

Also mein Gedanke war um die Daten versenden, war diese in einem Stream, z.B. die NetworkStream Klasse, zu schreiben. Da die Write und Read Methoden idr mit Byte Arrays aufgerufen werden, war es für mich logisch, dass meine Klassen Byte Arrays zurückgeben sollten.
Nachvollziehbar?

Ich habe noch ein paar Gedanken gemacht:
Sollte ich auf Serialisierung zurückgreifen?
Wie würdet ihr Verschlüsselung einbauen? Ich würde das ganze eher Flexibel haben wollen, damit selbst entscheiden kann was man nutzen möchte oder sollte ich das vorgeben?

Grüße

12.01.2021 - 18:56 Uhr

Beschreibung:

Ja was soll ich sagen ursprünglich wollte ich eine Gui Anwendung mit einem Download/Patch Server programmieren. Geplant war das man über die Gui die ausgewählte aktuallisieren kann.
Beim implementieren der Netzwetkschnittstelle habe ich dann gemerkt, dass ich das meine Anwndung ein Protokol braucht, das auf TCP/UDP aufbaut, damit es kommunizieren kann. Wer hätte das gedacht...
Naja meine Idee zu dem Protokoll habe ich jetzt Github veröffentlicht. Dabei ist anzumerken, das ich das eher Snippet sehe und weniger als Projekt. Auch weil viele grundlegende Dinge noch fehlen bzw noch nicht implementiert sind:

-Security - fehlt bisher vollständig, Kommunikation ist unverschlüsselt

-Typ Validierung - der Header verwendet einen generischen Typ für den Message Typ(Type) das führt mit unterschiedlichen Implementationen zu fehlern - hier habe ich noch keine Idee wie ich das Problem lösen könnte.

Aufgrund dieser beiden Punkte möchte folgendes Klar stellen:
Diese Libary ist nicht für den Produktiveinsatz vorgesehen und sollte auch nicht in Produktivumgebungen eingesetzt werden.

Wer es dennoch tut ist selber schlud.

Was kann ich jetzt damit machen?
Meins kann als Basis zur Weiterentwicklung dienen. Dabei sollte man aber mindestens beiden oben genannten Punkte beachten.

Auf welches Protokoll kann ich aufbauen oder welchen Server kann ich nutzen?
TCP und UDP sollten gehen. Eventuell kann man auch auf Mqtt aufbauen oder auch eine Serielle Scnittstelle. Vielleicht findet auch jemand ein Anwendungsbereich als Websocket Protokoll. Wie auch immer mein Protokoll ist nur darauf ausgelegt byte Arrays zu Parsen und zu erstellen, die man von oder in Streams liest/schreibt, wie z.B. den NetworkStream.

Code:
https://github.com/SuperSaurfang/GenericNetworkProtocol

Ich würde über Anregungen freuen
Grüße

30.11.2020 - 10:55 Uhr

Hallo,

Ich habe gestern festgestellt, das man die IPv6 Loopback Addresse nicht in die entsprechende IPv4 Loopback Adresse umwandeln kann bzw. das Ergebnis entspricht nicht dem was ich erwarten würde.

Die Loopback Addresseen sind ::1 für IPv6 und 127.0.0.1 für IPv4.

Wenn ich nun ::1 zu IPv4 mappe bekomme ich 0.0.0.1 als Ergebnis zurück, erwarten würde ich hier aber 127.0.0.1. Für Andere IPv6 Addressen scheint dies zu jedoch richtig zu Funktionieren.

Umgekehrt verhält sich die Methode MapToIPv6 bei IPv4 Addressen auch etwas seltsam.
So wird bei 127.0.0.1 folgendes einfach davor ::ffff: gehängt, das scheint generell bei jeder IPv4 Addresse der Fall zu sein.

Test App:


class Program
    {
        static void Main(string[] args)
        {
            var ipAddresses = Dns.GetHostAddresses("localhost");
            //var ipAddresses = Dns.GetHostAddresses(Dns.GetHostName());
            var ipAddress = ipAddresses[0];

            Console.WriteLine($"Loopback IPv6: {ipAddress.MapToIPv6()}");
            Console.WriteLine($"Loopback IPv4: {ipAddress.MapToIPv4()}");

            ipAddress = ipAddresses[ipAddresses.Length -1];

            Console.WriteLine($"Loopback IPv6: {ipAddress.MapToIPv6()}");
            Console.WriteLine($"Loopback IPv4: {ipAddress.MapToIPv4()}");

            Console.ReadKey();
        }
    }

Ausgabe für localhost:


Loopback IPv6: ::1
Loopback IPv4: 0.0.0.1
Loopback IPv6: ::ffff:127.0.0.1
Loopback IPv4: 127.0.0.1

Ausgabe für Hostname


Loopback IPv6: fe80::e83a:b1d0:426d:8f8d%21
Loopback IPv4: 66.109.143.141
Loopback IPv6: ::ffff:192.168.178.20
Loopback IPv4: 192.168.178.20

Ist das verhalten korrekt oder sollte ich das als Bug melden? Ich bin mir nicht sicher. Was meint ihr?

16.06.2020 - 16:54 Uhr

Hallo Leute,

Ich Probleme meine ASP.NET Core Webapi in den Docker Container zu bringen. Docker läuft bei mir unter Linux in einer VM auf Windows. Das Projekt habe ich unter Linux angefangen und unter Windows habe ich die Docker Ünterstützung für Linux hinzugefügt. Ich habe auch schon ein komplett neues Projekt erstellt ohne Code und ohne alles nur mit Docker Ünterstützung für Linux.

Es scheitert daran das ich beim Docker Build dotnet restore mit folgender Meldung fehlschlägt:


/usr/share/dotnet/sdk/3.1.301/NuGet.targets(128,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/app/DockerTestApp.sln]
/usr/share/dotnet/sdk/3.1.301/NuGet.targets(128,5): error :   Resource temporarily unavailable [/app/DockerTestApp.sln]
The command '/bin/sh -c dotnet restore' returned a non-zero code: 1

Ich habe schon im Internet danach gesucht, aber keine Lösung für mein Problem gefunden. Zuerst dachte ich, das würde irgendein Netzwerkproblem mit der Docker Bridge sein. Aber dies kann ich eigentlich aus folgenden Gründen ausschließen:

  1. Ich habe von Windows aus Zugriff auf Internet
  2. Ich habe von der VM aus Zugriff auf das Internet
  3. Die Beispiel Anwendung aus dem dotnet-docker Repo wird gebaut und ausgeführt in meinen Docker.

Ich habe mir auch den Container während des Builds vorgangs angesehen, die sln befindet sich in den Build Ordner.

Hier der Inhalt meines Dockerfile:


FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /app

# copy csproj and restore as distinct layers
COPY *.sln .
COPY DockerTestApp/*.csproj ./DockerTestApp/
RUN dotnet restore

# copy everything else and build app
COPY DockerTestApp/. ./DockerTestApp/
WORKDIR /app/DockerTestApp
RUN dotnet publish -c release -o /app --no-restore

# final stage/image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "DockerTestApp.dll"]

Weiß jemand weiter oder hab ich etwas vergessen?

Grüße

23.03.2020 - 18:06 Uhr

Hallo Leute,

Ich schreibe gerade eine .Dot Core WebApi, die auch eine Schnittstelle zur einer Datenbank bzw. zu den beiden im Titel Datenbanken genannten hat. Grundsätzlich funktioniert das auch, das ich eine der Beiden Datenbanken nutzen kann, je nach dem was in der Config eingestellt ist.
Meine Idee war dabei folgende:
Über eine Config Datei kann man festlegen welche Datenbank genutzt werden soll. Es ist nicht vorgesehen, beide Datenbanken parallel zu nutzen, es kann zur Laufzeit nur eine Datenbank genutzt werden. Wenn eine Andere Datenbank genutzt werden soll muss die Config angepasst werden und die Webapi neu gestartet werden.
Programmier Technisch habe ich das so gelöst, dass die Controller Klasse nur das Interface kennt, das je nach verwendeter Datenbank unterschiedlich implementiert ist. In der Startup Klasse wird je nach Config dann die entsprechenden Service Klassen aktiviert.

Grundsätze Frage: Was haltet ihr von der Idee unabhängig davon, dass das tatsächlich Funktioniert?

Nun zu meinen Problem:
Die MongDB verwendet ein komplett anderes Id System als eine SQL Datenbank, eine ObjectId, die für jedes "Object" in der Datenbank einzigartig ist. Während eine SQL Datenbank dafür idr. ein Integer als Primary Key und AI für eine Tabelle hat.
Meine Lösung wäre hier, das ich in der MongoDB noch eine Funktion implementiere mit der ich ein Feld hochzählen kann.

Grüße