Dela upp en Byte[] i flera små för att skicka via UDP?

Okej nice, suveränt.
Men finns det något vettigt sätt att räkna ut om ett paket är snabbare för mig än flera små (ofragmenterade)?
För kan inte direkt kolla och se skillnaden bara sådär verkar det som.

Ah, kanske var det som gav en vit linje längst ner på bilden som kunde fladdra lite, den var typ 1-2 pixlar hög och längden i bred.
för verkar inte få det nu tror jag.

EDIT:

Har stött på ett litet problem.

Additional information: Destination array was not long enough. Check destIndex and length, and the array's lower bounds.
i += data.Length-2;

Tror det är att filen blir för stor, för testade ändra min komprimering till LZ4, så det ser ut så här:

 pictureBox1.BackgroundImage = byteArrayToImage(Lz4.DecompressBytes(databyte));

byte[] u = Lz4.CompressBytes(imageToByteArray(holder), Lz4Mode.Fast);

Bilden är då BMP såklart, för annars förlorar jag ju på det.

Hmm, verkar löst sig när ja öka storleken på databyte. Är det möjligt att göra databyte oändlig/dynamisk?
För den behöver ju egentligen inte ha en fast storlek.

Suveränt, tjänar man på det?
tänker eftersom man måste skicka ett extra paket med info så kanske man förlorar på det i ren hastighet?

För är ute att göra det som ska göras, så snabbt som möjligt, alla milisekunder räknas.

EDIT:

Hmm den verkar fungera delvis, men tappar bilden väldigt ofta och är betydligt slöare tyvärr.
Men kanske blir mer risk när man ska ha ett paket som sätter storleken, eller?

Tack

Ska testa att ändra senare, och se om det funkar.

Adress är från en text ruta där ja skriver IP Adressen "213.12.123.123" typ.

BMP är snabbast såklart, och ja komprimmerar sen BMP med LZ4 för den ska vara jäkligt snabb.
Om ja skulle köra PNG rakt på istället, skulle det gå för sakta, PNG är jäkligt slött tyvärr.

Vill gärna testa på libjpeg-turbo. Men vet inte hur man använder det i c#, du råkar inte veta något om det?

Det verkar funka nu.

Men undrar, vad är den riktiga skillnaden från att ha en dynamisk byte array, från att sätta en enorm?
Tänker, tjänar man på det prestanda vis, eller är det bara med struktur att göra?

och när det kommer till buffern, vad gör den, för vill minska latencyn så mycket som det bara går, så vill inte ha någon hög buffer om det fungerar som ja tror det gör.

Och jo vet om inbyggda, men tror libjpeg lär vara betydligt snabbare och förmodligen bättre än windows egna.
iaf får ja det från det jag läst. Men vet inte om den är bunden till c++ eller nåt.

Okej det låter vettigt.

Hmm, när du säger tappade paket ökning, gills det också i LAN scenarion?

EDIT:

Verkar som det, kan ja räkna ut om ja tappar, så ja kan försöka mig fram att få så låg som möjligt?

Jo är det ja testat också.
Testade nyligen med en laptop, och då jäklar va det laggar, funkar prima på min dator när ja kör på min IP (alltså inte 127.0.0.1), men använder ja en annan dator så verkar det inte funka lika väl.

Hmm, vet inte va det kan bero på, om det är UDP i sjävl som strular till det, eller något annat.

Jo vet, men verkar som jag var lite för optimistisk om min laptop.
CPU och fläkten drar igång rejält och hela datorn slutar typ fungera, så är rätt värdelöst att testa med den.
Är klart prestandan som får det att hänga efter och inte nätverket i det här fallet.

På tal om prestanda, du vet inte om något bättre sätt att visa bild på bild än att anvädna picturebox?
Tänkte om man kunde ha något som gick på grafikkortet, typ renderings fönster, som man bara spammar på alla bilder som kommer in på?
För tror knappast en picturebox är menat att uppdateras kosntant som en film.

Tror det var jpeg ja testa. Men den laptopen är extrem fall.
På min dator kan det ta 4% och på den är det typ 70%.

Är någon extremt gammal singel kärnig CPU i den.

Men lär vara dekomprimeringen som slår ut den, möjligen också sättet ja använder picturebox, tror inte det är särskilt optimalt att uppdatera bilden hela tiden med den.

Juste, Om ja skulle vilja skicka via TCP hur gör jag då?
För har aldrig förstått mig på det.

Vet att man måste connecta först, vilket jag försökt, och sen att den ska lyssna och accepta clienten.
Men det verkar inte funka för mig, så antar att det är någonting jag missat?

Tcplisten har inte GetStream för mig;S

Ah såg nu, den skapar alltså en ny client när den får en uppkoppling?

Okej har skrivit så här och det går lite som det går.

  private void Listen()
        {
            System.Net.Sockets.TcpClient tt1 = tcplisten.AcceptTcpClient();
            System.Runtime.Serialization.Formatters.Binary.BinaryFormatter b = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
            while (checkBox1.Checked)
            {

                byte[] u = (byte[])b.Deserialize(tt1.GetStream());
                ms = new MemoryStream(u);
                pictureBox1.BackgroundImage = Image.FromStream(ms);
            }
        }

 private void Send()
        {
              System.Runtime.Serialization.Formatters.Binary.BinaryFormatter b = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
           
            while (capcon == true)
            {
              
                if (tcpcap.Connected)
                {
                    byte[] u = imageToByteArray(PrintWindow("Application"));

                    b.Serialize(tcpcap.GetStream(), u);
                }
                else
                {
                    tcpcap.Connect("127.0.0.1", 1700);
                }
}

Varierar beroende på vilken ja startar först, Recieve eller Send.
På Recieve får jag:

Additional information: Object reference not set to an instance of an object.
System.Net.Sockets.TcpClient tt1 = tcplisten.AcceptTcpClient();

Vilket jag inte direkt förstår, då ja har satt den ett värde och det.

Startar ja Send först får jag:

Additional information: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.

Det kan dock komma utifrån hur ja satt IP Adresserna, så tror inte det är något riktigt problem, problemet ligger nog i det förstnämnda.
b.Serialize(tcpcap.GetStream(), u);

EDIT:

Kanske fått igång det, hade satt Tcplisten två gånger, så ändrade det, verkar fungera:)

Yes funkar helt klart, äntligen har jag lyckats att använda TCP överhuvudtaget, man tackar så mycket, försökt i flera dagar utan någon nytta:)

Men undrar, TCP fungerar väl så här typ.

TCP client - > skickar paket - > TCP Server tar emot - > skickar bekräftelse till TCP Client.

Vilket med andra ord leder till 50% högre latency om ja tänker rätt?

UDP däremot, skickar bara på och på, sen hur det kommer fram struntar den i.
Men tack vare det har den 50% lägre latency för den bekräftar ingenting alls.

Det ja kör nu från dig är väl att man strukturerat UDP att fungera som TCP?
Man har markerat paket och den säger nej om alla inte kommer fram, eller?

Är det ja skulle vilja förhindra.
Ja är intresserad av att skicka så snabbt som möjligt.

Ja kan lätt klara mig på korrumperade bilder då och då.
Men tyvärr verkar det mer bli, ingen bild alls, för den kan inte äns få fram att set ska vara en bild om ja förstår rätt.

Ah okej.

Men underligt då att den funktionen verkar vara slöare en TCP funktionen ja testa nu, ska det vara så?
Tänker TCP vill ju bekräfta att allting kommer punkt och pricka.

Men din UDP funktion säger bara, oj 10paket har kommit, och vi ska ha 10, bra vi fortsätter.

I see, kanske har den mer att ge än ja trott.
För den fungerar jäkligt bra med NoDelay aktiverat, annars är den rätt seg märkte jag.

Däremot om filerna blir stora hamnar allt efter väldigt mycket, och det är inte nätverket som säger ifrån.

Jag är inte hundra på vad det är faktiskt.

Men, du nämnde att BinaryFormatter inte va särskilt snabb i alla dagar eller hur?

Ja försökte leta omkring om alternativ, och kom då över Protobuf som verkar vara det Google kör på, och NetSerializer.
http://code.google.com/p/protobuf/
https://github.com/tomba/netserializer
Men när ja använder dom, verkar det inte fungera, vet inte varför, men också vet ja inte hur det skiljer sig mellan dom, så kanske man måste ställa in eller liknande.