Ma sikerült 700 MBits/seccel adatokat átvinni titkosítva, tömörítve WCF-fel egy erős pc és egy szerver között. :)
Ehhez egyszerre 3 szerverre uploadoltunk fájlokat párhuzamosan, netTcpBindinggel, SSL-lel, a csatornán Deflate tömörítéssel (.NET 4.5).
Alapszabály, hogy HashSet, Dictionary vagy bármi más asszociatív kollekciókban kulcsként csak immutable objektumokat lehet használni. Ennek az az oka, hogy amikor berakunk egy elemet, akkor a kollekció meghívja az objektumon a GetHashCode-ot, és az azonos hashkódú objektumokat listába szervezi. Ha két objektum egyenlőnek tekintendő (az Equals alapján), akkor a hascodejuknak azonosnak kell lenni. Ha ez nem teljesül, vagy idővariáns, azaz később már nem igaz, akkor ezek a kollekciók meghülyülnek.
A példám így nézett ki:
public virtual bool Equals(EntityBase other)
{
if (other == null)
{
return false;
}
if (Id == 0)
{
//Transient object
return ReferenceEquals(this, other);
}
return other.Id == Id;
}
public override bool Equals(object obj)
{
if (!(obj is EntityBase))
{
return false;
}
return Equals((EntityBase)obj);
}
public override int GetHashCode()
{
return Id;
}
Eleve látszik, a GetHashCode és az Equals nem azonos logika szerint működik. A GetHashCode akkor ad vissza azonos hascodeot, ha az idk azonosak. Az Equals viszont az idtől függően vagy az idkat hasonlítja össze, vagy referenciális komparálást csinál. Ez már kapásból bug.
A másik bug, hogy ez az objektum nem immutable, az Id változik, amikor adatbázisba beszúrjuk az entitást, és kap egy idt. Emiatt az egész koncepció beteg.
A HashSet.Add meghívja a HashSet.AddIfNotPresetet, amiben van egy ciklus:
for (int i = this.m_buckets[num % this.m_buckets.Length] - 1; i >= 0; i = this.m_slots[i].next)
{
if (this.m_slots[i].hashCode == num && this.m_comparer.Equals(this.m_slots[i].value, value))
{
return false;
}
num3++;
}
Ez az ciklus akadt be. Az if feltétele sose teljesült, így sose lépett kis a ciklusból, mivel idt kapott az entitás, így megváltozott az Equals logikája.
Ilyet még nem csináltam, percall alapú szervizeknél félnék is a DI framework sebességétől, de ezzel a módszerrel be lehet vezetni a DI-t a szerviz infrastruktúra tövénél. Még kevesebb Service Locator antipattern lesz a kódban.
Hogyan bízzuk az sslt a load balancerre, és használjunk sima httpt mögötte, a wcf szervizekig?
A bemutatott trükkös megoldás jól jött volna tavaly, amikor az OEP TAJ ellenőrző szervizét nem tudtuk WCF-fel meghívni, mert nem SSL-en kér auth adatokat. Alapban a WCF ezt nem nyeli le, de a cikk megmutatja, hogy lehet átvágni.
Pár órám elment az életemből, mivel véletlenül abszolút elérési utat írtam be endpoint addressnek egy WAS (IIS) alatt hoszolt WCF szervizbe. Jó szokásától eltérően nem jött semmi világos hibaüzenet, mi a baja a WCF-nek.
Érdekes írás Fowlertől, hogyan alakult ki a REST, ami ma már inkább Hypermedia API. Nekem a vége kicsit fura, amikor már kezd beszivárogni valami interfészleírás-szerű valami, így pont az eddig egyszerűség kezd elveszni.
Jó kis összefoglaló a témáról, miért kellett ASP.NET-be újra megcsinálni a dolgokat.
Hoppá, már nem házilag kell megoldani. Jövő héten kipróbáljuk.
Tömör konklúzió: ha küldünk át credentialokat, akkor a beépített ChannelFactory cache nem működik, kézzel kell cachelni. Ha nem (ez a ritkább), akkor megy magától.
Részletek itt.
Ez érdekes, eddig csak megakadályozni lehetett, így már szimmetrikus a dolog. Persze, ettől még nem fogja inlineolni a jitter amit nem lehet, pl. virtuálisokat.
http://blogs.msdn.com/b/bclteam/archive/2006/09/08/746900.aspx
Az IIS appol identityt is bele lehet rakni a hivatkozott csoportba, csak kézzel kell beírni a nevét, nem lehet kiválasztani az explorer listájából.
Vannak aranyosak, de ez ronda, sunyi. De könnyű megoldani a cikk alapján.
Végre van egy jó kis okos dumpoló eszköz. Ami szopó volt eddig pl., ha 64 biten taskmanaggerrel csinálsz egy 32 bites processzről dumpot, akkor azt nem lehet rendesen elemezni pl. sos-sel.
Persze van 32 bites task manager is: C:\Windows\SysWOW64\taskmgr.exe. Ezzel már jó a dump.
De a procdump automatikusan jó dumpot készít, nem kell variálni. Like.
Ráadásul mindenféle feltételek mellett is képes dumpt készíteni, pl. lefagyásnál vagy exceptionnél, hasonlóan mint eddig az adplus iishez. Like very much. :)
HashSetbe akartam berakni hibernate entitásokat, amelyek Equals-sza és GetHashCode-ja így nézett ki:
public virtual bool Equals(EntityBase other)
{
if (other == null)
{
return false;
}
if (Id == 0)
{
//Transient object
return ReferenceEquals(this, other);
}
return other.Id == Id;
}
public override bool Equals(object obj)
{
if (!(obj is EntityBase))
{
return false;
}
return Equals((EntityBase)obj);
}
public override int GetHashCode()
{
return Id;
}
A HashSet.Add-nak beadva egy ilyen entitás példányt az Add soha nem tért vissza, végtelen ciklusba került. Miért?
Szeretetteljes boldog karácsonyt kívánok minden kedves ismerősömnek, barátomnak. Gyerekeseknek betegség nélkülit, nekünk ez az első, amikor mindenki egészséges. :)
Van egy vpcm, amit havonta egyszer elő kell vennem, és dolgozni rajta 10 percet. Mivel Windows 8-ban nincs vpc, a hyperv-t nem támogatja a laptopom, betette a gépemre a lábát az ellenség keze, és felraktam a VirtualBoxot. A vpc fájlt simán át tudtam konvertálni, aztán már indult is.
CLR attributumokban sajnos nem lehet használni nullable típusokat, mivel ezeket metaadatként tárolja el a compiler, és az nincs felkészítve struktúrákra. Igazából még a decimalt sem eszi, ami elég bosszantó, ez azért beleférhetett volna.
Most mégis kellett nullable és ráadásul decimal att param, így kerültem ki:
public class SteppingSpecificationAttribute : Attribute
{
private double increment;
private double startValue;
private double endValue;
public SteppingSpecificationAttribute(double defaultValue)
{
DefaultValue = defaultValue;
}
public bool HasValueIncrement { get; private set; }
public bool HasValueStartValue { get; private set; }
public bool HasValueEndValue { get; private set; }
public double Increment
{
get { return increment; }
set
{
increment = value;
HasValueIncrement = true;
}
}
public double StartValue
{
get { return startValue; }
set
{
startValue = value;
HasValueStartValue = true;
}
}
public double EndValue
{
get { return endValue; }
set
{
endValue = value;
HasValueEndValue = true;
}
}
public double DefaultValue { get; set; }
}
Nem elegáns, de működik. Valakinek van jobb ötlete?
Később, amikor kiveszem a property-k értékét, akkor nézem meg, mi null és mi nem, valamint akkor konvertálok decimalra. A double-decimal konverzió okozhat adatvesztést, de ismerem milyen számok mennek be, ezekkel nincs ilyen gond.
Az egyik programomból SMS-t akartam küldeni, ha gond van vele. Skype apival ez nagyon egyszerű:
public class SmsSender
{
public static void Main()
{
new SmsSender().SendSms("+36XXXXXXXXX", "Test");
}
public void SendSms(string phoneNumber, string smsText)
{
ISkype skype = new Skype();
ISmsMessage ismsmessage = skype.CreateSms(TSmsMessageType.smsMessageTypeOutgoing, phoneNumber);
ismsmessage.Body = smsText;
ismsmessage.Send();
}
}
Valszeg létrehozok neki egy saját skype accountot, rakok rá némi pénzt, aztán jöhet az sms.
A fentihez kell a Skype Desktop API, amihez kicsit hosszadalmasan regisztrálni kell, és a végén kapunk egy COM DLL-t, azt interoppal triviális hívni, mint fent is látható.
Szegény Code Contracts még másodrangúbb szereplő lett, úgy érzem. VS 2012-ben fel sem jön a plusz füle, hiába telepítjük a Code Contracts csomagot.
Elevated VS 2012 Command Propmtból devenv.exe /setup -pal a helyére kerül a dolog. (Vigyázni, a 2012-es devenvet futtassuk.)
