Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » VC++ / MFC » Fehler bei Casyncsocket?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 < [ 3 ]
010
06.08.2002, 15:52 Uhr
~Merciless
Gast


Hi,
WSAEWOULDBLOCK ist nicht unbedingt ein Fehler,beim verbinden
kann es vorkommen das der andere Rechner noch blocken will,
nach ner kurzen Zeit aber frei ist um anschließend bereit zu sein.
Das passiert auch wenn du z.B. mehr Daten sendest als er empfangen kann,
dann blockt er ne Weile ab,leert seinen Buffer und ist wieder frei für Daten.
Normalerweise ignoriert man den Fehler beim verbinden,sollte
er jedoch zu lange blocken (Timeouts können helfen *G*),
dann nutzt die Verbindung nix,aber das muss ich wohl nicht schreiben *G*

MFG
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
06.08.2002, 19:01 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Wie kann man Timeouts setzen?
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
07.08.2002, 02:30 Uhr
~Merciless
Gast


z.B. so:

FD_SET t_Set;
TIMEVAL t_Timeout;

t_Set.fd_count = 1;
t_Set.fd_array [0] = m_Socket; //In dem Array kann man mehrer Sockets
//einfügen,wo auf Events gewartet werden
//kann
t_Timeout.tv_sec = 10; //10 Sekunden warten
t_Timeout.tv_usec = 0; //Wer microsekunden braucht....
//der select() Befehl gehört zur Winsock Library
select (0,&t_Set,NULL,&t_Set,&t_Timeout);

Der Befehl wartet so lange bis Daten empfangen werden oder ein
SocketError entsteht oder eben der Timeout.

Allerdings kannst du Timeouts auch umgehen indem du auf
das OnSend () event wartest,das ebenfalls
bescheid gibt,das du wieder was senden kannst.
Ist in der CSocket (oder CAsyncSocket) vorhanden.
Allerdings fand ich in der Praxis es immer etwas umständlicher
zu nutzen,vielleicht gefällt dir das ja mehr *G*
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
07.08.2002, 07:42 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Hmm schön und gut,

nur das nützt mir im grunde nix, das Problem ist, das ich nicht weiß wie man überprüfen kann ob die verbindung auch wirklich besteht, wenn Connect 10035 zurückgegeben hat, dann könnte ich die erstmal von PC2 ankommenden Daten erstmal zwischenspeichern und sobald ne verbindung besteht die daten weitersenden (mein aufbau siehe unten)

PC2 (ultima online client) <-LAN-> PC1 (dlrouter, mein prog) <-DSL-> Internet (draveland, uofreeshard)

Im Moment funktioniert es eben nur, wenn man lange genug wartet um sicherzugehen das pc1 ne verbindung aufgebaut hat (zum server, inetverbindung besteht), sobald aber der pc2 die verbindung zu pc1 trennt, startet mein programm die verbindung ins internet neu, nur das funktioniert nicht! Kommt immer folgendes:


Code:
Connect: Connect command to "draveland.dnsalias.com:02593" sent, waiting for connection
OnConnect: The specified address is already in use.



Warum das?

Ich hab die Sockets mit Shutdown() und Close() vorher geschlossen (benutze CAsyncSocket), liegt es daran das ich den gleichen lokalen Port zum verbinden wieder benutze?
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
07.08.2002, 12:27 Uhr
~Merciless
Gast


ARGH,da war eh nen kleiner Fehler drinne im Timeout,
da beim select () da oben der 2. Parameter eins nach rechts muss um
auf einen freien Buffer des anderen Rechners zu warten,so wartet er
auf eine 'OnReceive()' Message.

hmmm also das sollte nicht sein,wenn du vorher Shutdow und Close
aufgerufen hast.Das Problem kann man jedoch mit setsockopt() und
dem Parameter SO_REUSEADDR umgehen.

Außerdem habe ich im im Source der MFC nachgeguckt und
der WSAEWOULDBLOCK wird dort automatisch behandelt,
kann sein das der Server gar nicht frei werden möchte oder
gar nicht das TCP/IP Protocol unterstützen.
Sich mit einem Ultima Server zu verbinden ist auch
keine geeignete Testplattform,wer weiß wie das da abläuft.
Z.B. benutzt das Chat Tool zu Anfang beim einloggen
eine Mischuns aus dem TCP/IP und UDP Protocol.
Ich bin mir auch nicht sicher ob Ultima TCP/IP nutzt,da ich
von 3D Shootern und anderen Games her es so kenne,das die das UDP Protocol benutzen.
Am besten du machst eine Testplattform auf deinem eigenen Rechner
und probierst erstmal so damit zu testen.

Wie schon erwähnt,in meiner private Socket Klasse ignoriere
ich beim verbinden WSAEWOULDBLOCK und warte,wenn
der Fehler auftaucht mittels eines Timeouts,bis der Socket sich
als 'frei' zeigt.Wenn das nach X Sekunden nicht passiert
will der Server halt nich,weil er überlastet ist oder aus
irgendsnem anderen Grund nich will *G*

MFG
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
07.08.2002, 14:21 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Naja ich ignoriere auch WSAEWOULDBLOCK, im Moment funktioniert es soweit das er sich in den server einloggen kann und der client in mein programm, nur:
Bis der client sich einloggt speichere ich daten in ein chararray zwischen, welche mir der server gesendet hat (hab auch gespeichert wie lang der string ist), senden zum clienten sobald er sich einloggt funktioniert auch, nur weshalb auch immer sendet er von meinem programm nix zum server!

wenn Send aufrufe, gibt es mir exakt die länge zurück welche ich übergeben habe, (kein socket_error), nur nach firewall sendet er nix!

Warum das?

Ich hab das Socket mit

m_asRemote.Create(1015,FD_READ|FD_WRITE|FD_CONNECT|FD_CLOSE);
geöffnet (kein error)

bei connect kam eben WOULDBLOCK, sobald nun etwas vom Server kommt, geht mein 2tes socket auf listen und der client kann connecten.

Dann bekommt der client das, was der server mir gesendet hat (funzt)
Dann sendet der client was, das mein programm eigentlich weiterleiten sollte, nur der sendaufruf sagt ok, die firewallstatistik sagt was anderes.

Was kann man da machen?
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
016
07.08.2002, 16:26 Uhr
~Merciless
Gast


oha,schon wieder:
Ich meinte das Chat Tool ICQ welches beim einloggen UDP und TCP/IP Mischmasch macht.Naja,war eh net so wichtig *G*
Und nen Protocol Prob scheins somit auch ausgeschlossen ehhehe

hmmm,ok ich versuche mal zu folgen:
Der 1.Socket verbindet sich mim Server,wo du ihm dann
(gehe ich mal von aus) bescheid gibts,wo dein 2.Socket
seinen geöffneten Port hat.Der Ultima Server verbindet
sich dann mit deinem 2.Socket und dann sendest du direkt
über den 2.Socket? Denn wenn dein 2.Socket ein Listening Socket ist,
dann vermute ich jetzt mal einfach,das der Fehler folgendermaßen ist:

Wenn das OnAccept () Event aufgerufen wird,dann bekommst
du einen ganz neuen Socket mitgeliefert (den "rConnectedSocket" in der MFC),mit diesem Socket kannst du dann weiter mit dem Server kommunizieren,der andere Socket der bleibt noch im Listening Modus
stehen.Ich gehe auch mal davon aus,das du den nicht mehr brauchst
(oder würde dieser Ultima Server noch mehr Verbindungen wollen?).
Dann schließe den listening Socket und benutze den neuen Socket,
wo bereits dann eine Verbindung steht und man über den weiter senden
muss.

hmm und die Firewallstatistik...hmmm,da der ja keinen Socket Error liefert,
sollten zumindest theorhetisch die Daten angekommen sein.
Aber wenn du ne INet Verbindung hast und nen Win OS (ka,wies in Linux so ist),dann könnteste ja auch mal bei diesem blauen Symbol in der Taskleiste
schaun,der sollte auch alle übertragenen Bytes anzeigen,die rausg-
rein kamen

MFG
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
017
07.08.2002, 16:32 Uhr
Merciless



warum immer kann ich den Post nich editieren :-(
Aber hatte was vergessen,da ich seit langem nimmer
mit Sockets und MFC proggte.

Also,der rConnectedSocket der bei OnAccept übergeben wird,
muss natürlich dann mit deinem Listening Socket und
der Accept () Methode übergeben werden,danach kannste
den Listening schließen und den neuen benutzen.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
018
07.08.2002, 19:04 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Ich glaub du verstehts micht falsch,

ich hab 2Rechner, einer mit dem uoclient, den anderen mit meinem programm und internet, die verbindung programm internet geht und die verbindung uoclient programm geht, nur das senden von daten programm -> internet funktioniert nicht, obwohl die verbindung ok ist und Send keinerlei errormeldung liefert.
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
019
07.08.2002, 22:03 Uhr
mike
Pinguinhüpfer
(Operator)


Hi!
Ich hab noch nicht soviel Ahnung von NTs ( ich hoffe, dass ändert sich eines Tages ).
Aber einen Versuch ists Wert: Ich hab folgendes in „Inside Visual C++“ gelesen (Es ist in Kap. 34 und ich bin erst bei Kap. 13 – also wenn’s falsch ist – sorry)

Unterstützung für Proxy-Server
Wenn Ihr Rechner in ein LAN innerhalb eines Unternehmens eingebunden ist, ist es relativ wahrscheinlich, dass er nicht direkt, sondern über einen Proxy-Server, gelegentlich auch Firewall genannt, mit dem Internet verbunden ist. Es gibt zwei Arten von Proxy-Servern: Web- und Winsock-Server. Web-Proxy-Server, die gelegentlich auch als CERN-Proxies bezeichnet werden, unterstützen lediglich die Protokolle HTTP, FTP und Gopher. (Das Gopher-Protokoll, das HTTP vorausging, ermöglicht textorientierten Terminals den Zugriff auf Internet-Dateien.) Ein Winsock-Client-Programm muss für die Verwendung eines Web-Proxy-Servers besonders angepasst werden. Ein Winsock -Proxy-Server ist flexibler und kann daher Protokolle wie RealAudio unterstützen. Statt den Quelltext Ihres Client-Programms abzuändern, binden Sie eine spezielle DLL ein, die mit einem Winsock-Proxy-Server kommunizieren kann.

mfg mike
--
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 < [ 3 ]     [ VC++ / MFC ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: