Probaj sa ovim:



umesto security mode="None"

Probao i to.
Stavio sam taj deo na klijentu i serveru i dobijam exception:
"The requested upgrade is not supported by 'net.tcp://server:4857/'. This could be due to mismatched bindings (for example security enabled on the client and not on the server)."

Tj. ne, moja greska. Bio sam probao <transport clientCredentialType="None" /> i tu je bila ta greska. Sa tim sto si dao kaze:

"A remote side security requirement was not fulfilled during authentication. Try increasing the ProtectionLevel and/or ImpersonationLevel."

Moras na obe strane taj security.

Meni ovo radi isprobano (doduse preko pipes, ali bi trebalo ista prica da ti vazi i za TCP). Malo je "tvrdje" od security="None" jer samo iskljucuje Windows authentication na TCP bindingu, ali bi moralo da ti radi. Evo ti moj config:

I jesam na obe strane probao obe varijante (i clientCredentialType i protectionLevel). Uvek iste u isto vreme :). Evo, trenutno su mi identicni config fajlovi kao ovi tvoji, samo je TCP umesto Named Pipes i nema ovih parametara maxReceivedMessageSize i readerQuotas i sl. Ali kontam da to nije ni neophodno.


E da, setih se sada da pomenem da komp na kojem je server nije u domenu a na kojem je klijent jeste. Ali, ako je iskljucena autentifikacija, to ne bi trebalo da ima veze...

Edit: isto se desava i kada pokrenem oba na istom kompu.

Ok, sad sam probao, definitivno u svim varijantama sljaka security mode="none", okacio sam ti primer prostog wcf servisa koji radi prako toga (testirano i u lolcahost i unutar i van domena i sa van domena na domen).

Jedini potencijalni problem je sto je comm link nekriptovan pa sniferi mogu da vide sve sto radis (pogledaj npr prikaceni capture komunikacije sa nedomenske masine na domensku koji sam snimio, treba ti network monitor da bi video sadrzaj). security mode="transport" bi to trebalo da resi ali cak i kad se iskljuci cliencredentials nece da radi van domena, mislim da u pozadini odradjuje domensku authentikaciju masina i mislim da ima neki nedokumentvani switch da se ovo iskljuci, pogledacu.

Glupo pitanje, si izbusio port 4857 na serverskom firewallu?

Pa, ako se konektuje kada podesim credentials, valjda znaci da firewall propusta. Nisam ga ni gledao, mada mislim da je skroz i iskljucen (masina je unutar privatne mreze i radi samo to). Pogledacu za svaki slucaj, tj. iskljuciti ga.

Jel ti radi ovaj primer koji sam ti dao?

Radi.
/me totalno zbunjen :)

Probaj opet svoj proram sa sceurity mode="none" (tamo gde si dobijao timeout) ali pre paljenja klijenta proveri dal server stvarno slusa na portu (netstat)

Probao.
Sve isto, dobijam na klijentu exception:
"The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.9659966'."

InnerException je:
"An existing connection was forcibly closed by the remote host"


Port je otvoren. Proverio i sa netstat-om i sa TCPView. Dodao sam i ServiceBehavior koji nisam imao a vidim da imas u tvom projektu.
Jedino ne znam zasto na serveru imas ovaj drugi endpoint:



Osecam da ce na kraju biti neka epic glupost u pitanju...

Taj servicebehavior i endpoint ti nisu neophodni (mogao sam ih i skloniti na kraju). To je metadata servis endpoint, sluzi za dinamicko otkrivanje servisa (npr u klijentu onda ne mroas da pises rucno ceo app.config vec mozes da dodas servis kroz "Add Service" dugme a VS ce pokupiti contracte kroz IMetadataExchange. behavior dodatno sluzi da service host eksponira taj interfejs automatski (da ne moras ti da pises rucno implementaciju kad su sve metadata informacije vec prisutne u running service hostu).

Ajd da krenemo drugim pritupom
posto ocigledno nisi koristio dinamicko otkrivanje to znaci da koristis isti interfejs i na serveru i na klijentu. Kako inicijalizujes klijenta i kako inicijalizujes WCF instancu?

Da, koristim isti interfejs na oba. On se nalazi u zasebnom .dll-u koji sam napravio u trecem projektu i referencirao i iz klijenta i iz servera. Vise mi se svidjalo nego ono sto sam nalazio u primerima da koristim onaj program koji mi pravi kopije pa kad menjam na jednom mestu moram uvek to da koristim...

Na serveru, imam klasu koja implementira taj interfejs. U sebi takodje sadrzi:
private ServiceHost Host = new ServiceHost(this);

Startujem sa Host.Open();

Na klijentu imam klasu:
public class ServerProxy : DuplexClientBase<Interfejs>, Interfejs

Implementacije svih metoda zapravo samo pozivaju base.Channel.MethodName kao na primer:
public void DoSomething()
{
base.Channel.DoSomething();
}


Zatim imam klijent klasu koja implementira Callback interface i u sebi sadrzi:
ServerProxy Server = new ServerProxy(new InstanceContext(this));
Server.InnerChannel.Open();

Hmm, ti koristis duplex kanal, zar nije za njega obavezan endpoint sa obe strane. Ne znam napamet, nisam do sad radio duplex servis ali ako server moze van poziva da uradi callback to bi trebalo da znaci da i client ima svoj endpoint na kojem slusa, zar ne?

Mozda pogresno posmatramo taj exception, mozda to ne znaci da server odbija konekciju vec da mozda kllijent odbija serversku callback konekciju i onda uzvrati exceptionom kroz primarni kanal....


I btw, sa mex servisom stvari su mnogo jednostavnije i ustedis tonu kucanja jer na kraju ti on odradi sam sve. A ako izmenis bilo koji od contracta update je one-click-away:


_{[Ovu poruku je menjao mmix dana 24.11.2009. u 15:09 GMT+1]}

Ne mora.
Kada klijent pozove neku serversku funkciju u njoj mozes da dobijes CallBack objekat sa:
OperationContext.Current.GetCallbackChannel<IIntrefejs>();

Ono sto pozivas tom interface-u se poziva na klijentu, Naravno, klijent mora implementirati taj interface i prilikom konektovanja biti prosledjen:

Server = new ServerProxy(new InstanceContext(this));

To "this" je Client koji implementira IInterfejs.


Sve ovo radi kada ja stavim da se koristi Windows autentifikacija (ok, ima jedan problem na jednom kompjuteru al' o tome cemo drugi put).
Ali ako stavim da nema security - nece.

Ma ja se samno prisecam slicnih problema iz doba remotinga.

Pazi ovako, mozda gresim, ali mozda i ne, da bi slao callback nazad ti uzimas taj CallbackChannel sto bi u pozadini trebao da bude novi TCP channel od servera ka klijentu, osnovni channel je u state-u poziva servera i callbacks ne mogu da idu preko njega (ima tu i grdjih problema od razdvajanja paketa preko tcp protokola, npr kako bi izveo mix&match callbacka i rezultata za wsHttp binding gde svaki response mora da ima soap envelope). E sad, ako mu ti sam ne navedes koji jecallback channel on vrlo verovatno otvara svoj sa default podesavanjima koja ukljucuju windows authentication (vidis problem, glavni kanal je noAuth, callback kanal je auth). Resenja ovog problema bi onda bilo u rucnom konfigurisanju callback kanala. Opet kazem mozda rgesim jer nisam radio duplex servise.

Ja iskreno nisam voleo ni evente u remotingu jer nisu reliable a callbacks u WCFu su nastavak te price... Jel ti to stvarno neophodno ili je ono, cool to have

Neophodno je. Server povremeno salje informacije klijentima bez njihovog striktnog zahteva.
Jos cu na kraju da shiznem i da batalim wcf skroz i radim samo sa TCP-om... A taman je poceo da mi se svidja :)
Videcu oko te mogucnosti sto si rekao da je callback auth.

Sad sam provalio da ne mogu da se konektujem ni u lokalu, kada su server i klijent na istoj masini sa <security mode="None" /> :S

Pa worst case scenario ako ne mozes da utices na formiranje kanala je da manuelno uradis ono sto DuplexClientBase radi automatski, dakle napravi da klijent hostuje drugi servis onda preko prvog servisa registrujes klijenta na serveru i onda server ima List<Client> strukturu gde svakoj od tihs truktura odgovara ClientBase<Clientservice> preko cijih kanala saljes pozive klijentima.

Pa bar po MSu ne bi smeo uospte da mozes bilo kako da radis duplex u lokalu:



sto ce reci ako pozivas server na portu 12345 kroz duplex klijenta onda klijent otvara listenera na svojoj IP adresi na portu 12345 (koji je btw u lokalu vec zauzet serverom ;))

Kada stavim
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>

Radi u lokalu :)

eto loodila :) moguce i da dinamicki otvara slobodan port ali onda to ne resava inicijalni problem. Zato mi sva ova apstrakcije ide na zivce, kad nesto jednostavno ne radi nigde ne mozes da nadjes informacije o tome kako to nesto radi i gde je zglajznulo.

ajd pogledaj nesto ako te ne mrzi, vidi koji je PID klijent aplikacije i kad pozoves server vidi koji port je otvorila za listen...

Hocu, ali tek sutra, kada mi bude ponovo dostupno :)

A znas da su sa mnom uvek neke lude stvari :)

Sad ces me mrzeti

moj adaptiran security mode="none" duplex servis radi u lokalu i posvuda ostalo Inace, callback koristi isti network pipe po kojem je stigao poziv (drzi konekciju alive) i zbog toga ima neka ogranicenja, radi samo u tcp/pipe bindingu (ne moze za soap) i radi samo za servise koji zahtevaju sesiju (verovatno to odrzava konekciju u zivotu). tako da se sve vraca po istom linku a verovatno ima neki redirector u prijemnom delu koji mu govori da li je result poziva ili je callback zahtev.

pogledaj moj promer, vidi po cemu se razlikuje od tvog...

Ne mogu ovo da pokrenem ovako kako je. U app.config dobijam warning:
The element 'transport' cannot contain child element 'extendedProtectionPolicy' because the parent element's content model is empty.

Odnosi se na <extendedProtectionPolicy policyEnforcement="Never" />

Ukoliko sve to uklonim i ostavim samo <security mode="None" />
Radi.


Moj program - identicno podesavanje (samo je drugi port i drugi contract) - ne radi. Da nema veze mozda sto je kod tebe net.tcp://localhost:12345/shadowyService ? Ja boldovani deo nemam. Mada, kako god okrenem, kontam da bi trebalo da ili ne radi nikako ili radi svakako, kod mene se samo razlikuje da li je security podesen na windows (tada radi) ili na None (tada ne radi, cak ni preko localhost-a).

mozda je neki takav bug u channel-u, mada endpoint uri ne bi trebalo da ima veze sa tvoj problemom ako nemas vise servisa na istom portu, uri cisto sluzi da vise endpointa moze da se smesti na jedan tcp port. Uostalom ako je bug mozda dolazi do izrazaja ako je uri skresan, probaj da dodas neko ime servisa u uri sa obe strane i vidi dal radi. Mozda niko ranije nije koristio go uri pa niko nije ni naleteo na bug :)

extendedProtectionPolicy mislim da su uveli u 3.5sp1, jedna od slabo dokumentovanih stvari, ako nemas 3.5sp1 izbaci slobodno, obavezan je samo da bi radio wcf izmedju tog frameowrk i ranijiih verzija.

Na kraju smo zajednickim trudom i najnovijim svemirskim tehnologijama pozajmljenim iz NASA-e utvrdili da binding nije ucitan jer umesto bindingName="bnd" treba bindingConfiguration="bnd"