I have several "blackbox" that sends data to determinated IP and PORT, I can´t specify anything else (just IP and PORT)...
My server should be listening that PORT and catch information to send to MSMQ...
How can I set a WCF server to listening that PORT?
Thanks!
I would write a normal windows service that listens for the data.
Use the TCPListener or a similar class
Then plug on WCF as a seperate service that your windows service calls to write to the message queue, it's just a matter of configuration.
[ServiceContract]
public interface IDaraWriterService
{
[OperationContract]
public void WriteDataToQueue(WriteDataToQueueMessage theDataEncapsulatedInAMessage)
{
}
}
Your windows service could probably write to the queue directly btw.
See here for more info on the message queue. http://msdn.microsoft.com/en-us/library/ms811053.aspx
If you can control what's pushing data to the IP address/port, then yes, you could use WCF. Unfortunately, without some sort of contract/binding to specify the means by which your "server" and your "client" communicate, WCF won't help you much.
So if you can't control the client code, you'll need to "roll your own" listener. As #Rob Stevenson-Leggett suggested: TcpListener
Edit:
Thanks Randolpho... So, I´ll develope
a Windows Service with the listener
and add the message to MSMQ. And in
the otner hand, I need a module to
read the queue (MSMQ) and add that to
DB... That module could be in WCF?
What you think?
Yep. WCF provides the MsmqIntegrationBinding for communicating on either end with an MSMQ.
Here's a nice tutorial:
http://msdn.microsoft.com/en-us/library/ms789008.aspx
Related
I'm trying to let my service knows when one of the clients is disconnected.
I'm using wsDualHttpBinding.
Currently, I'm tried to use this event :
OperationContext.Current.Channel.Closed += new EventHandler((sender, e) => ClientIsDisconnected(sender, e, currentCallbackChannel));
But this event is never fired...
Please help me to know how it'd be done !
Edit :
Thanks to anderhil, I finally replaced wsDualHttpBinding by netTcpBinding (with the appropriate configuration described here : http://msdn.microsoft.com/en-us/library/ff647180.aspx#Step1).
With netTcpBinding, the Closed event fires without any problem... Still don't know why but it works.
The issue you are having is likely becuase of WsDualHttpBinding. In case you have this binding, two connections are created, from client to service and from service to client.
When the application is deployed over the internet it can create some issues with supporting such applications, you need to be sure that people are not behind the firewall or NAT or etc that can prevent your service to connect back to client.
I still don't know why it doesn't work on local machine when testing, but i will try to resolve it and update the answer.
As you told me more details in our chat, from the nature of your application it's better to use NetTcpBinding. In this case it's easier to understand what is happening cause one connection is created, and you will receive the notifications in case of gracefull close or abort of client.
As i told you before, anyway it's better to create some heartbeat mechanism to have things more reliable in case of unexpected computer or router shutdown.
Also, you can find this good cheat sheet on how to select communication between parties that involve WCF:
The Closed event should occur on a graceful disconnect; is that what's happening?
To detect the pure socket disconnect, listen for the Faulted event:
OperationContext.Current.Channel.Faulted += new EventHandler(FaultedHandler);
My situation: I have an xspeech for voip, when there is an action about phone, the messages(packets) are sent to the xspeech interface. And from this interface the logs of these action are sent to specific IP address which is my IP address. And also these logs are sent from a specific port.
I am trying to develop an application that reads these logs(not a file). I tried TCPListener and TCPClient, they worked but not in my situation. I thought these logs are not sent from TCP port. This is the problem.
From your post I suspect it is using UDP... this would mean that you need to use UDPClient class to receive and process...
Depending on whether they offer a TAPI provider you can use:
http://www.codeproject.com/KB/IP/devangpro.aspx
http://www.codeproject.com/KB/dotnet/CShart_TAPI_3x.aspx
http://www.codeproject.com/KB/IP/Video_Voice_Conferencing.aspx
http://msdn.microsoft.com/en-us/library/ms734214.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms734257%28v=vs.85%29.aspx
It may be necessary to build a SIP proxy (this would be able to generate for example "Pickup event"):
http://www.codeproject.com/KB/cs/SIP_stack_with_SIP_proxy.aspx
http://sipsorcery.codeplex.com/
http://www.independentsoft.de/sip/index.html
http://www.konnetic.com/products/products_sip_sdk_std.aspx
http://www.voiceelements.com/Products/VEToolkit.aspx
EDIT - as per comments other possibilities:
If what you try to catch is sent as syslog message then see http://michael.chanceyjr.com/useful-code/syslogd-class-for-sending-and-receiving-syslogd-events/ .
Another possibility is SNMP - for this see http://www.snmpsharpnet.com/
SIP uses UDP per default.
It's not as simple as being able to take packets from one endpoint, log them and then send them to the real destination. You'll break things like NAT handling if you do so.
You need to act as a full SIP proxy (stateful) or as a B2BUA.
The easier way is to download an existing sip-proxy and just make it log to a file and read that file.
If you're recieving the information on at your IP address then I too would have thought that TCP/IP was being used. Have you checked that your firewall isn't blovking the port in question.
I would suggest that you have another look at what protocol is being used (it may be UDP) and use the Socket class instead.
I'm trying to add networking over the internet to my game, using Peer to Peer.
I have already implemented a LAN only version, which uses .NET's peer to peer classes to connect within the local network.
I realized I need to use UDP hole punching in order to establish a connection to other clients that are behind a firewall.
This is how I have started to implement it:
The server is a HTTP server using very simple PHP scripts to get the job done.
register name on server, sending the private ip address and port as a GET variable
when the server gets a registration request, it will save the public endpoint and the private endpoint
request to connect to another client.
the server will return the private and public endpoints of the client
every two seconds, the second client will check in with the server, and if there is another client attempting to connect with it, it will get its endpoints too
both clients start spamming each others public endpoints until they get a valid response
Now I have a bunch of questions
Can the server be a HTTP server?
When I make a request to an HTTP server, the client port changes each time a request is made. Is a private endpoint always matched to the same public endpoint?
Does the request to the server have to have the same source endpoint as the UDP messages to the client?
Is there a way to connect to an HTTP server in C# using a specified source endpoint?
Are there any problems with my implementation?
Thanks!
UDP hole punching is a complex topic, and many attempts have been made to find a solution that works. The problem is that there are so many different NAT routers out there, and there is no standard way of implementing NAT, so all routers behave a bit different.
Some attempts have been standardized, e.g. STUN, ICE. They still work only in most cases, not all, but they accumulate a lot of knowledge and address many concerns -- more than your attempt will ever be able to, simply because you can't test your solution with every NAT router under the sun. Skype, for example, spent years of perfecting its NAT traversal mechanism.
I recommend you have a look at STUN or preferably ICE. Try to implement one of them or look for existing implementations.
Another option might be to simply create a port forward at the router, e.g. using UPnP or NAT-PMP.
That said, I wouldn't be surprised if the .NET peer to peer classes came with a NAT traversal mechanism, but I'm not familiar with them.
STUN is a best solution for the problem. it works for most of the scenarios.here is a simple example(C#) that gives you the NAT type,Local IP:Port and Public IP:Port.
try
{
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.Bind(new IPEndPoint(IPAddress.Any, 0));
STUN_Result result = STUN_Client.Query("stunserver.org", 3478, socket);
Console.WriteLine("Net Type : " + result.NetType.ToString());
Console.WriteLine("Local IP : " + socket.LocalEndPoint.ToString());
if (result.NetType != STUN_NetType.UdpBlocked)
{
Console.WriteLine("Public IP : " + result.PublicEndPoint.ToString());
}
else
{
Console.WriteLine("");
}
}
catch (Exception x)
{
Console.WriteLine(x.StackTrace.ToString());
}
You can just add some breakpoints and check the behaviour of the code.
also you can traverse NAT using vs2010 onwords (.net4.0 < ) . there is a method AllowNATTraversal (bool value). set the value true for NAT Traverse. It uses Ipv6 address for connectivity. You can get Ipv6 global address from "Teredo" server by writing some commands in command prompt. Actually IPV6 is the technology that is used to avoid this problem.
I've a plugin which always listening to the port 6002, and i have an ASP.net application which sending messages to the same port and receiving the reply from the plugin on the same port,
Sending is working fine, and the plugin sends a reply on the same port but i don't know how to catch this reply, when i try to listen to the same port using Tcplistener the start method throws this exception : Only one usage of each socket address (protocol/network address/port) is normally permitted,
is there any way to catch the received message
Thanks
It sounds like you are wrongly assuming that the Socket which you get from TcpListener.AcceptSocket can only be used in one direction.
Sockets can actually be bidirectional. You can use Send to send something, and Receive to listen for get the replies. Open one socket, and then use it for both sending and receiving.
In short, no.
Once a port is opened an exception will be thrown if further attempts are made to utilise that same port from a different source - as you are experiencing right now. There isn't a way to get around this.
I've solved this problem using this way ,, I know it's old method but it's working !! :
'/*Variables Initialization*/
dim objSocket, strServicePort, strIpAddr, strResult, strMsgTo, strMsgResponse
strServicePort = "6002"
strIpAddr = "127.0.0.1"
'/* Create a TCP/IP socket. */
objSocket = Server.CreateObject("Intrafoundation.TCPClient.3")
objSocket.ClearLog()
'/* Establish socket connection. */
objSocket.Open (strIpAddr,strServicePort)
objSocket.Timeout=60.0
strMsgTo ="---- Message here ----"
'/* Send request message to plugin */
objSocket.SendRN(strMsgTo)
'/* receive XML Request Message from plugin */
strMsgResponse = objSocket.Recv()
strMsgResponse = Replace(strMsgResponse, vbLf, "")
objSocket.Close()
If you want to inspect traffic you can use winpcap.
edit: I don't think you are asking the right question. In this case the plugin is the server (listening on port 6002) and your ASP.net app is the client listening on some arbitrary port. You only need to bind to a different port in your ASP.net app if it also needs to run as a server with the plugin acting s the client. In this case you should pick a different port even though there are, in fact, ways to make it work when they are both bound to the same port.
In your case though you should just read back responses from the connection you established from the client.
My WCF server needs to go up and down on a regular basis, the client sometimes uses the server, but if it is down the client just ignore it.
So each time I need to use the server services I check the connection state and if it's not open I open it.
The problem is that if I attempt to open while the server is down there is a delay which hits performance.
My question is, is there a way to do some kind of myClient.CanOpen()? so I'd know if there is any point to open the connection to the server.
There is an implementation of WS-Discovery that would allow you to listen for up/down announcements for your service. This is also a very convenient form of service address resolution because it utilizes UDP multicast messages to find the service, rather than configuring one set address on the client.
WS-Discovery for WCF
There's also an implementation done by a Microsoft employee:
WS-Discovery Sample Implementation
.NET 4.0 will include this natively. You can read about .NET 4.0's implementation on Jesus Rodriguez's blog. It has a great chart that details the ad-hoc communication that goes on in WS-Disco Using WS-Discovery in WCF 4.0
Another thing you might consider, especially if your messages are largely one-way, is a protocol that works natively disconnected, like MSMQ. I don't know what your design for your application looks like, but MSMQ would allow a client to send a message regardless of the state of the service and the service will get it when it comes back up. This way your client doesn't have to block quite so much trying to get confirmation that a service is up before communicating... it'll just fire and forget.
Hope this helps.
If you are doing a synchronous call expecting a server timeout in an application with a user interface, you should be doing it in another thread. I doubt that the performance hit is due to exception overhead.
Is your performance penalty in CPU load, gui availability or wall clock time?
You could investigate to see if you can create a custom binding on TCP, but with faster timeout.
I assume you know that "IsOneWay=true" is faster than request->response in your case because you wouldn't be expecting a response anyway, but then you are not getting confirmation or return values.
You could also implement a two-way communication that is not request->response.
If you were in a local network it might be possible to broadcast a signal to say that a new server is up. The client would need to listen for the broadcast signal and respond accordingly.
Here's what I'm using and it works like a charm. And btw, the ServiceController class lives in namespace 'System.ServiceProcess'.
try
{
ServiceController sc = new ServiceController("Service Name", "Computer's IP Address");
Console.WriteLine("The service status is currently set to {0}",
sc.Status.ToString());
if ((sc.Status.Equals(ServiceControllerStatus.Stopped)) ||
(sc.Status.Equals(ServiceControllerStatus.StopPending)))
{
Console.WriteLine("Service is Stopped, Ending the application...");
Console.Read();
EndApplication();
}
else
{
Console.WriteLine("Service is Started...");
}
}
catch (Exception)
{
Console.WriteLine("Error Occurred trying to access the Server service...");
Console.Read();
EndApplication();
}
I don't think it's possible doing a server side call to your Client to inform him that you the service has been started ... Best method i can see is having a client method figuring out where or not the service is open and in good condition. Unless I am missing some functionality of WCF ...
There is a good blogpost WCF: Availability of the WCF services if you are interested in a read.