I am developing a communication layer between client and server using XMPP in c#. The requirement is to send message from client and halt execution until a reply is received from server. Is there any way of doing that using agsXMPP?
Another thing is I don't want server to synchronize the message sending/receiving. It should be only client waiting for the reply. Server should work asynchronously.
Please help if there is any thing available.
You can use standard XMPP IQ requests with your own payload. IQs are specially designed for situations when reply is required.
In agsXMPP there is an IqGrabber class, which can be used to send query and perform callbacks on the query response.
Related
I need to write a C# application that will sit and run as a service on a windows server.
This application will be responsible for sending JSON snippets to connected clients.
Clients will be connecting using an Asynchronous WebRequest and I want to Gzip encode the payloads to reduce the size of the packets being sent down the wire to each connected client. The data being sent to each client will differ so I need to manage all the connections as well.
Once a client is connected, they will remain connected for as long as possible, so the server will be sending heartbeats every x number of seconds.
I have not done programming like this since my days back in uni and wondered what the best way of achieving this was?
Can I use Sockets and standard TCP/IP with the WebRequest connection method?
I went with the HttpListener in the end.
I'm trying to build a simple multithreaded tcp server. The client connects and sends data to server, the server responds and waits for data again. The problem is I need the server to listen for incoming data in separate thread and be able to send command to client any time (for example to notify about new update). As far as I understood, when ever client sends data to server, if server doesn't respond with any data, client app doesn't let me send more data, server simply doesn't receive them. If I send data ether way around, does the data need to be 'acknowledged' for tcpclient?
Here's the source for the server: http://csharp.net-informations.com/communications/files/print/csharp-multi-threaded-server-socket_print.htm
How can I make the server send command to a client in separate thread outside the "DoChat" functions loop? or do I have to handle everything in that thread? Do I have to respond to each request client sends me? Thanks!
The problem is I need the server to listen for incoming data in separate thread
No, there is an async API. You can polll a list of threads to see which ahve new data waiting, obcviously to be done froa worker thread.
As far as I understood, when ever client sends data to server, if server doesn't respond with any
data, client app doesn't let me send more data, server simply doesn't receive them.
That is a lot more crap programming than the way sockets work. Sockets are totally ok with streaming ata in sending and receiving direction att the same time.
How can I make the server send command to a client in separate thread outside the "DoChat"
functions
Wel, me diong your job costs money.
BUT: The example is retarded. As in- totally anti pattern. One thread per client? You will run into memroy problems and perforamnce problems once 1000+ clients connect. You get tons of context switches.
Second, the client is not async because it is not written so. Mayy I suggest giong to the documentation, reading up on sockts an trying to build that yourself? THEN come back with questions that show more than "i just try to copy paste".
With proper programming this is totally normal. I have a similar application in development, sending data lall the time to the client and getting commands from the client to modify the data stream. Works liek a charm.
If I send data ether way around, does the data need to be 'acknowledged' for tcpclient?
Yes and no. No, not for TCP - TCP does it'Äs wn handshake under the hoods. Yes, if your protocol decides it has to, which is a programmer level design decision. It may or may not be necesssary, depending on the content of the data. Sometimes the acknowledgement provides more information (timestamp server side, tracking numer) and is not pure ly there for "I got it".
We want to implement a client server application. here is the scenario.
Server listens for client 24/7.
Server accept request for client and save it in DB for further process.
Once processing is done (it may take few hours), Server will response back to client.
in short , client and server listens for each other 24/7.
I want to implement it in C# but i also want that it should be accessibly from all platforms.
Also is it possible in WCF?
I agree with Yuck, this is a basic WCF scenario. There a few articles, videos and tutorials to get you started here http://msdn.microsoft.com/en-us/netframework/dd939784
I have a task to do and I am new to networking, so like to discuss before coding down. I have to write down server side UDP application. Server listens for connection request from many clients (could be 100 or more). When it receives it then it does some handshake, by sending acknowledge back and forth couple of times, with the client application to know its identity. When connection is established it receives different types of data from the clients which it does processing and put in the sql database and send acknowledge back to client. Periodically send command to clients for specific information it requires.
I am using C# with Visual Studio 2005. Should I use multi threading? threadpool? Asynchronous or sync UDP Server?
Thanks in advance.
Are you sure what you want is a UDP server? Terms such as "connections", "handshakes" are all TCP related.
I would use asynchronous methods in both the server and the client. It will complicate things, especially in the client.
The reason is that you write that the server will send stuff to the client sometimes. This makes a simple request/reply type of communication impossible (the client calls Send and then uses Receive until a proper answer have been received).
If you can scrap that requirement I would use synchronous clients (do some polling instead) which would make stuff a lot easier for you to understand.
If you have .Net 3.5, why don't you create a WCF service instead? It supports TCP and callbacks (server can call stuff in the client).
I have a client-server app where the client is on a Windows Mobile 6 device, written in C++ and the server is on full Windows and written in C#.
Originally, I only needed it to send messages from the client to the server, with the server only ever sending back an acknowledgement that it received the message. Now, I would like to update it so that the server can actually send a message to the client to request data. As I currently have it set up so the client is only in receive mode after it sends data to the server, this doesn't allow for the server to send a request at any time. I would have to wait for client data. My first thought would be to create another thread on the client with a separate open socket, listening for server requests...just like the server already has in respect the client. Is there a way, within the same thread and using the same socket, to all the server to send requests at any time?
Can you use something to the effect of WaitForMultipleObjects() and pass it a receive buffer and an event that tells it there is data to be sent?
When I needed to write an application with a client-server model where the clients could leave and enter whenever they want, (I assume that's also the case for your application as you use mobile devices) I made sure that the clients send an online message to the server, indicating they were connected and ready to do whatever they needed doing.
at that time the server could send messages back to the client trough the same open connection.
Also, but I don't know if that is applicable for you, I had some sort of heartbeat the clients sent to the server, letting it know it was still online. That way the server knows when a client was forcibly disconnected from the network and it could mark that client back as offline.
Using asynchronous communication is totally possible in single thread!
There is a common design pattern in network software development called the reactor pattern (look at this book). Some well known network library provides an implementation of this pattern (look at ACE).
Briefly, the reactor is an object, you register all your sockets inside, and you wait for something. If something happened (new data arrived, connection close...) the reactor will notify you. And of course, you can use only one socket to send and received data asynchronously.
I'm not clear on whether or not you're wanting to add the asynchronous bits to the server in C# or the client in C++.
If you're talking about doing this in C++, desktop Windows platforms can do socket I/O asynchronously through the API's that use overlapped I/O. For sockets, WSASend, WSARecv both allow async I/O (read the documentation on their LPOVERLAPPED parameters, which you can populate with events that get set when the I/O completes).
I don't know if Windows Mobile platforms support these functions, so you might have to do some additional digging.
Check out asio. It is a cross compatable c++ library for asyncronous IO. I am not sure if this would be useful for the server ( I have never tried to link a standard c++ DLL to a c# project) but for the client it would be useful.
We use it with our application, and it solved most of our IO concurrency problems.