Jump to content
  • Advertisement
Sign in to follow this  
plywood

inbound stream sockets?

This topic is 3790 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

(Winsock) I am just rolling up my sleeves with Windows-based socket programming and want to create a simple application. I have partially read beej's guide (which, although it caters mainly to the Linux/UNIX community, still has a *plethora* of good info for winsock programming) and some winsock-specific guides, but they weren't able to answer my questions at hand. I am interested in creating a client-side-only connection to a port on my own machine, and monitoring *any and all* data that comes in on it. I am *not* interested in actually establishing a connection with any network device sending data to that port. Is this possible; a sort of "inbound-traffic-only" TCP (stream) socket? If so, how? Else, why not? Any clever circumventions around this?

Share this post


Link to post
Share on other sites
Advertisement
libpcap.

It may not be able to capture traffic between local applications though, but that's the limitation of network stack itself.

Share this post


Link to post
Share on other sites
Not to my knowledge. TCP is connection oriented. You will at the very least listen on the port, accept connections and just not send anything. Network sniffers and their kin would be the best place to look for that sort of behavior/implementation.

Share this post


Link to post
Share on other sites
Antheus,

I will check libpcap out.

Is it really *that* difficult to set up a "1-way" socket (listening/receiving only) socket? My original guess was that it would involve something like creating a sock_addr that binds to a local port but does not connect() to the server on the other side.

If it is this easy - or comparable - I would just do it myself without libpcap. But something tells me you are going to swat that idea out of the sky...

Share this post


Link to post
Share on other sites
Telastyn,

If I took your suggested route and just set up a listening socket, would that in any way "block the port" and disable it from being connected to by other apps?

Share this post


Link to post
Share on other sites
Quote:
Original post by plywood
Telastyn,

If I took your suggested route and just set up a listening socket, would that in any way "block the port" and disable it from being connected to by other apps?


You're using 'connected to' incorrectly I think.

To be precise: If you're listening on a tcp port, no other app can listen on that port. A listening port can accept many connections.

Share this post


Link to post
Share on other sites
Okay, I think that maybe I'm not explaining this right, and in addition to that since I'm a newb I am probably using terminiologies (e.g. "connected to", etc.) improperly!

So what I want is this:

There are two client applications, A and B, running on LocalMachine. Client A uses winsock to create a stream socket bound to port, say, 150 (whatever), and to then communicate to remote Server C over the internet via local Port 150.

When TCP/IP packets come in to LocalMachine's Port 150 from Serve C, Client A interprets those raw bytes into a Widget object, whatever you fancy that to be.

Meanwhile, Client B, also listening on Port 150, interprets that same raw data into a Food file structure, again whatever you want that to be.

Thus, two distinct applications running on LocalMachine, are listening on the same port, and interpreting the incoming data totally differently.

I am looking for a way to develop Client B. That is, an application that binds to a port - regardless of whoever else is listening, sending and receiving from that port, and simply recv()'s incoming data for interpretation.

thanks for any help here guys!

Share this post


Link to post
Share on other sites
No. Something like that will require more than standard socket use. Further, it only has 2 common game related uses:

A) inspecting a packet stream to see why your game's net code is broken.
B) looking into the raw packet stream of a game to edit and/or spy on it.

and let's just say, I don't think it's A given the thread so far...

You'll get no help on that other front from me.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!