• Welcome to Valhalla Legends Archive.
 

Direct Connection

Started by WiLD, October 18, 2003, 12:46 PM

Previous topic - Next topic

WiLD

Ok this is alittle hard to explain but ill try my best. im trying to add soething to my bot (secret =P) but it needs to connects. Its meant 2 connect sorta like Stealth bot's tic tac toe.

i want it so some1 can host which calls DRhost but it needs to send its ip 2 the others for them 2 connect by calling DRconnect.

So id like some help with the code. iv tried so many times but it wont work.
MAP:
Host Invites > Whispers IP > Calls DRHost > Connecters Recive IP > Calls DRConnect

Thank you in advance
=_=  &&  g0dFraY  &&  -=Templar=-  @USWest

Grok

Oh, you mean a trojan.

What you described is fine.  Have the trojan contact your listening process, which receives the connection address, then launches its own connection to the listening trojan.

Hope this helps.  And hope you burn in hell.

UserLoser

Quote from: Grok on October 18, 2003, 02:46 PM
Oh, you mean a trojan.

What you described is fine.  Have the trojan contact your listening process, which receives the connection address, then launches its own connection to the listening trojan.

Hope this helps.  And hope you burn in hell.

Haha ;D

Adron

Show your nonworking code.

Banana fanna fo fanna

You won't want to hear this, but the best way is to write a UDP-based protocol to solve the problem of NAT traversal.

I wrote a working implementation in Python...I could make it a COM server if you want to use it in VB.

WiLD

No its not a trojan if ya really want to know its a chat window. Kinda like Bnet Channels but only invited users can join and you can "DRAW" in it.

it all works untill i try to send the host's ip.
im about to redo the chat window just to make sure.

P1 Right click a user & invite > Sends invite to P2 > P2 Accepts > P1 starts hosting & chat window appears > P1 sends IP to P2 > P2 recieves IP > P2 connects to IP.
i hope that helps some understand abit more. it all works up till "P2 connects to IP".
=_=  &&  g0dFraY  &&  -=Templar=-  @USWest

hismajesty

I wrote a *harmless* trojan back in the day. It wouldn't connect to anybodys computer but mine though. Still, good times.  :P

CrAz3D

I member that, didn't it work on my computer for a little?
rebundance - having or being in excess of sheer stupidity
(ré-bun-dance)
Quote from: Spht on June 22, 2004, 07:32 PMSlap.
Quote from: Adron on January 28, 2005, 09:17 AMIn a way, I believe that religion is inherently evil, which includes Christianity. I'd also say Christianity is eviller than Buddhism (has more potential for evil).
Quote from: iago on April 19, 2005, 01:06 PM
CrAz3D's ... is too big vertically, at least, too big with ... iago ...

hismajesty

Quote from: CrAz3D on October 19, 2003, 11:12 AM
I member that, didn't it work on my computer for a little?

I don't think so..but who knows.

MyndFyre

Quote from: WiLD on October 18, 2003, 07:33 PM
No its not a trojan if ya really want to know its a chat window. Kinda like Bnet Channels but only invited users can join and you can "DRAW" in it.

it all works untill i try to send the host's ip.
im about to redo the chat window just to make sure.

P1 Right click a user & invite > Sends invite to P2 > P2 Accepts > P1 starts hosting & chat window appears > P1 sends IP to P2 > P2 recieves IP > P2 connects to IP.
i hope that helps some understand abit more. it all works up till "P2 connects to IP".

Part of the problem with connecting over TCP/IP is that a network user's IP address is different when you're sitting behind a firewall.  So, if I have a home network on subnet FF.FF.FF.00, and I want to invite someone to chat, here's how the exchange goes:

Me to You: (whispered via bnet) privatebotchat begin
You to Me: (whispered via bnet) privatebotchat ack send ip
Me to You: (whispered via bnet) privatebotchat ip 192.168.0.147

Your computer then tries to connect with sockets to 192.168.0.147.  Unfortunately, that's on a different subnet and behind a firewall; I wonder how many computers in the world have an IP address that begins with 192.168.0.  I know all three of mine at home do.

Part of the way to succeed with this is to use a tunneling protocol or a datagram protocol like (someone above) suggested with UDP.  Unfortunately, UDP is not absolutely reliable; messages can be lost (whereas in TCP/IP, an ACK is sent on successful receipt, or else the packet is re-sent), so you'd need to implement some kind of SEND/ACK/NACK protocol in addition to your messages.

Hth,

--Rob
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

iago

192.168.0.* is default for LAN on windows, but I doubt anybody uses those for external ip.
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Tuberload

Quote from: Myndfyre on October 23, 2003, 07:29 PM
Your computer then tries to connect with sockets to 192.168.0.147.  Unfortunately, that's on a different subnet and behind a firewall; I wonder how many computers in the world have an IP address that begins with 192.168.0.  I know all three of mine at home do.
iago already answered this, but it is simple to see how many people on the internet could have an IP address that begins with this, 255...

QuotePart of the way to succeed with this is to use a tunneling protocol or a datagram protocol like (someone above) suggested with UDP.  Unfortunately, UDP is not absolutely reliable; messages can be lost (whereas in TCP/IP, an ACK is sent on successful receipt, or else the packet is re-sent), so you'd need to implement some kind of SEND/ACK/NACK protocol in addition to your messages.

Hth,

--Rob
You could implement your own packets that made sure the packet was received using UDP. When the server sends data over a UDP protocol just have it wait for a response with a seed, or something. If it does not receive that response the client did not receive the original packet. I guess that could keep bouncing back and forth though determining whether the confirmation packet was received or not.
Quote"Pray not for lighter burdens, but for stronger backs." -- Teddy Roosevelt
"Your forefathers have given you freedom, so good luck, see you around, hope you make it" -- Unknown

Adron

Quote from: Myndfyre on October 23, 2003, 07:29 PM
Part of the way to succeed with this is to use a tunneling protocol or a datagram protocol like (someone above) suggested with UDP.

I don't think UDP will help you get through firewalls at all. Trying to connect to a private IP will fail with any protocol, unless you're on a VPN with the target or similar.

CupHead

The easiest way to avoid problems like that is to not be on a private IP yourself.  That way, you can simply ask the other party over the established connection (b.net presumably) to connect to a listening port that you've set up on your computer.  When both parties need their addresses translated, I'm not sure how to do it programatically.

Adron

Quote from: CupHead on October 24, 2003, 08:21 AM
The easiest way to avoid problems like that is to not be on a private IP yourself.  That way, you can simply ask the other party over the established connection (b.net presumably) to connect to a listening port that you've set up on your computer.  When both parties need their addresses translated, I'm not sure how to do it programatically.

Go via a third party, look up your external IP through someone outside, or use UPnP?