|
-
Aug 30th, 2002, 01:29 PM
#1
Thread Starter
Junior Member
udpClient (sockets) problem.
Is it me or is the sockets implementation useless in .Net?
When using VB6 I used the winsock control to talk to a server (UDP)
When connecting to the server if the wrong port was used to program would continue but no reply would be sent. Great.. no problem.
With .Net no error is recieved when the wrong port is used and therefore when the recieve command is used (which causes the system to wait for a reply) the program stops. But seeing as a reply is never received then it never starts again.
Is the some kind of timeout that can be set for the udpclient?
Thanks Imogen
Last edited by Imogen; Aug 30th, 2002 at 01:56 PM.
-
Aug 30th, 2002, 02:11 PM
#2
Thread Starter
Junior Member
Last edited by Imogen; Aug 30th, 2002 at 03:21 PM.
-
Aug 30th, 2002, 03:45 PM
#3
Well its not useless..its just that its not as friendly as the old winsock was..alot of the stuff winsock used to do for you, you have to kinda code yourself..for instance requestID..if you want a requestID for accepting connections, you have to code that..i use Guid.NewGuid() to create those. Now as far as what you should do, I would suggest doing a search around for a premade udp class for .NET where someone has done the coding to make it more winsock like.I HAD a TCP class I wrote a while back, but I lost it..
-
Aug 30th, 2002, 03:58 PM
#4
Thread Starter
Junior Member
Thanks, I managed to acheive what I wanted though.
I started the whole UDP connection in a new thread then just checked 10 seconds later (my timeout) if the thread had stopped. If it didnt I aborted the thread.
I think actually the point I was trying to make was that with VB6 you were supplied with many controls/dll to perform certain functionality. e.g. the winsock control. But they didnt supply them with .Net. OK they supplied the classes so you could produce your own, but I would have thought that MS would have at least wrapped them up to provide the equivalent of VB6 offerings.
This would have helped the transition a lot. I feel it would have been easier to find out how they worked and tweak them to specific needs.
Thanks again.
PS know anything about debugging threads? 
Imi
Last edited by Imogen; Aug 30th, 2002 at 04:05 PM.
-
Sep 1st, 2002, 07:03 AM
#5
Thread Starter
Junior Member
Unfortunately the only classes I can find are based in TCP sockets, not UDP 
Thanks though
Imogen
-
Sep 1st, 2002, 05:55 PM
#6
Thread Starter
Junior Member
Well in this instance I would have to disagree.
I have tried for days to get the UDP class to work (asking on all sorts of forums, inc this one) and it still either hangs when waiting for a reply (single thread) or never kills the thread in a multiple thread environment. So in the end I have 15 instances of the thread waiting for a connection. (more if I keep trying to connect)
I HAD a TCP class I wrote a while back, but I lost it
Thats the thing, with TCP being a connection based protocol its easy to check whether you are connected or not. You can't do this with UDP 
But I can't change the server (which is UDP) done for speed sending short messages not large files.
Alot of work for something that takes 5 mins in VB6.
I am having to go back to using the VB6 OCX in .Net which REALLY pains me as now I have to register an ocx on users machines Isn't .Net supposed to do away with that need?
The first little project with vb.net and I a bit cheesed off with it already.
As usual micrsoft fix the bits that arent broken.
ah well back to DLL hell 
Imogen
Last edited by Imogen; Sep 1st, 2002 at 05:58 PM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|