I need to create a server application that will take the TCP input from an Ethernet webcam and retransmit the packets to two different ports. The reason for this is that I want to connect to a webcam feed with two different programs (using one program locks the feed, making the connection unavailable for anyone else).
Can anyone please say if this is possible and perhaps provide some pseudo code. I am new to network programming and I am not sure on the best way of proceeding.
Have a look at a basic TCP sockets tutorial such as this one.
In short, you can use TcpListener to detect incoming connections, TcpClient to store and interact with those methods server side, and make them client-side. You'd need a listener for the webcam connection, a client to hold that connection, and two more to route it's input into.
I've also create this gist this one (Thanks #jgauffin), that contains an working example program that does this, and two programs you can run to test it and see how it works. It's a bit too detailed for a SO answer, so I'll leave it there and let you examine it yourself.
Related
I was wondering it it was possible to relay a socket object in either C# or Java? (Preferably C#)
I have lots of little programs i make and host them on my home pc, but my pc is behind a router, so i have to forward a port on my router every time i want to make a new application. So is there a way to send a tcp connection to another application on the same computer? for instance i get a connection in with the first line of text being RELAY::21005 which would then forward that port to localhost:21005 ?
Any help, tutorials, code snippets would be much appreciated. Thank you! :)
One problem you might face with your suggested solution (first line identifies target port) is that you'll have to change all of your client programs to send that first line. That's easy for programs you've written yourself but not so convenient if you want to connect to your PC's web server or ssh daemon etc. It's not impossible of course, but does make it hard.
I'd suggest your routing server listens on two ports - a control port and a "normal" port (I can't think of a better name at the moment). You would send control messages to the control port to indicate "until further notice redirect all incoming connections on the normal port to port nnnn". That avoids having to manipulate client protocols.
I don't know enough C# to provide advice about a C# solution, but in Java I'd simply do something like:
while (true) {
acceptConnectionOnNormalPort()
connectToTargetPort()
startThreadCopyingDataFromAcceptedPortToTargetPort()
startThreadCopyingDataFromTargetPortToAcceptedPort()
}
You'd not be able to scale that easily into thousands of connections...
K I take back my comment, check this out:
http://msdn.microsoft.com/en-us/library/aa395195.aspx
Using this requires the port sharing service to be up (it is disabled by default):
The Net.TCP Port Sharing Service is available on all operating systems
that support .NET Framework 3.0, but the service is not enabled by
default.
All of this is only useful to you if you are using WCF services tho.
The easiest approach IMO is to use ssh tunneling. As I wrote in my comment, there are lots of questions on SU that will show you how to do this.
But assuming that you want to program something ...
You'll need to create a client and a server. The client will have threads that call accept on whatever local ports you want to open. When a connection comes to a port, you create another thread that opens a connection to the server and continually sends data over the wire.
The server program listens on a single port, which you open in your firewall. It waits for connections on that port, and when it receives one it opens a connection to the specified local port. Then it shuffles bytes from one to the other.
The only trick is that you have to define a protocol for specifying the destination port in the client-server stream. Simplest approach is to write a two-byte integer at the start of the stream.
Yes, it is possible to relay a socket.
You can use TURN http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT
Some of TURN library/application:
pjnath
turnserver.sourceforge.net
I'm a Jr. Engineer hoping to seek some advice from all of the experienced people in here in regards to how to approach this.
I've been assigned a project to create a server/client application that does byte streaming through TCP. Our company deals with 2-way radios with GPS with a dispatch software and we would like to make a server/client application out of that. Currently the dispatch software can be hooked up to a central base station where a user has to be, but we want to make this software accessible from a remote location (if the base station is by a repeater miles away from where a dispatcher can be at).
User/Client -> poll location of a mic -> server -> base station -> OTA signal -> radio and back
I've been looking at Windows Communication Foundation, but what are other ways I can approach this?
I'll be primarily using C# / .NET / Visual Studio 2008
We have used UDP to send GPS updates from cars to a server that processes the updates. In applications like that (where you often have limited bandwidth) you can really tell the difference (in terms of how long it takes to get the data from the remote host to the server) between UDP and momentary TCP connections (like HTTP). A UDP packet will get to its destination in what seems like an instant, and the setup for the TCP connection is very conspicuous, often taking several seconds to complete. I like the WCF framework, but if your app is the sort of system I've been working with, I doubt you'll be happy with it (...unless it's OK to have a long interval between updates).
Lately, I've been working with persistent TCP connections (using raw Sockets), which is a good way to go if you want to make sure your packets arrive at their destination. Though the way to do that, I believe, is to leave the connection open as long as you can and incorporate code to reconnect it if it breaks.
If you just want a raw byte stream, then a Socket or the slightly more encapsulated TcpClient might be a more light weight solution.
But if you want to send complete data structures and "call functions" then WCF seems like a good choice.
With WCF you have a programming experience close to calling regular methods with real objects as parameters, but with a Socket you just send byte arrays and need to interpret the result all by your self.
I need to create a program that lets me send a string of data or a file through modem, like hyper-terminal does. Im trying to create a program that lets me send electronic billing data to Medicare, and since Medicare only accepts e-bills through modem, only hyper-terminal or another program called PC ACE Pro32 can be used.
I want to create my own program, since hyper-terminal is not user friendly, and the other program has too many things for just sending data.
I've never before had experience creating code for data communication. Can somebody please help me?
There are a lot of pieces here, so let me break this down into sub questions for you:
1) How do I do serial communication in C#?
There are plenty of examples on the internet. A quick search turns up this one and this one, both of which seem to be ok. There are also lots of questions here on SO about C# serial communication.
2) How do I control a modem?
Modems are operated by some version of the AT command set. If you're familiar with manually operating a modem in HyperTerminal, you're essentially doing the same thing, but in code. For example, to test if your modem is paying attention (i.e., that your serial line is talking to the modem properly), you send AT, and see if the modem replies with OK. To dial, you send the modem ATDT <phone number>. Once a modem establishes carrier, then whatever you send down the serial port is transmitted to the remote computer.
3) How do I communicate with medicare's electronic claims system?
This one is up to you! I'd be surprised if they didn't have a web-based claims service though. I would expect that would be a lot easier than doing it over a modem.
Define a receiving connection in remote computer.
Set up a connection to remote computer just like any dial-up connection.
Use socket programming (TCP) to send/receive data to/from remote computer. Note that you must create a client/server application that resides in both remote and local computer.
Seth, your answer is actually very promising. Ill be taking a look at those suggested links right away.
(yes, medicare should be moving to ethernet, but reality is that they are stuck in dialup because they say that "it's more secure than ethernet", when in reality it's not.
What makes more sense?
use one socket to send and receive data to/from a embedded hardware device
use one socket to send data and separate socket to read data
Communication is not very intensive but the important point is to receive data as fast as possible. Application works under Windows XP and up.
Sockets were designed for two way communication, so most likely the developers of the embedded device didn't design their system to work off two sockets.
I have some experience working with embedded hardware and I've seen them work various ways:
Device connects to your application and starts streaming data via UDP
In this scenario I've seen up to three sockets in play. One TCP listening socket that accepts a connection from the embedded device. The embedded device then sends through some connection parameters, such as how quickly it's going to send you the data. The embedded device then starts streaming data via upd. Once you've received the data you send a message down a second upd socket to say "I got that one". The device then starts streaming the next bit of data (again via upd). This then continues ad infinitum. I've seen variations where the initial TCP connection is skipped and device just constantly stream data.
Request/Response
How many sockets you'll need here depends on who's making the initial connection, as that'll determine who needs the listening socket. Since you're making the initial connection, I'll use that. This is the more connection oriented scenario. Here you make a connection to the device and request some data, the device then sends you the response to that data. In this scenarioyou can only use one socket. As the device will respond to each request on the socket it was received.
So to answer you question "What makes more sense?", it completely depends on the design of your embedded device. If it's responding on the same socket as you're requesting, the answer is simple as only one socket is possible. Streaming devices via upd should give better performance with two sockets, but again only if your device supports it.
As for the second part of your question, "to receive data as fast as possible.", that's easy go asynchronous. Here are some excellent blogs on asynchronous socket programming:
.NET Sockets - Two Way - Single Client (C# Source Code - Included)
.NET Sockets in Two Directions with Multiple Client Support (C# Source Code Included)
If you're using a custom/third party protocol to communicate with the device you can't go wrong having a read through these either:
How to Transfer Fixed Sized Data With Async Sockets
Part 2: How to Transfer Variable Length Messages With Async Sockets
Im no expert but is there any downside to just using one socket?
It can already send and receive and my guess is that you end up getting more overhead if you have one socket for reading and one for sending...
I'm tyring to add a feature to my app that sends a nudge to all users of my program (family members inside the house), and when they receive the nudge the window of my app on their computer shakes for a second...
Can somebody please suggest how i'd have to go about this? I've never worked with tcp/ip before.. Is this what I should use, or is there something better?
I have tried to come up with my own solution however none of the samples ever work. So I thought maybe the people on SO might know of other ways?
Thank you :)
If this is just an "in-house" (pardon the pun) application, and you're all on the same network, you might consider sending a UDP broadcast packet. Each instance of your application could listen for a packet on a particular port, and when the correct one is received do the window shake thing.
You might consider UDP for this. Since you can broadcast/multicast via UDP it may be more suitable for this sort of application. There are downsides - UDP transmission is not reliable or guaranteed in the same way as TCP.
I'd go with a good XMPP Library. Maybe Jabber-Net?
You'll also have the added bonus of being able to connect to Google Chat and now Facebook chat later.
You haven't specified if presence in your case requires a server or not. If it is client/server oriented, using XMPP gives you the server side for "free" as a bonus.