I've been searching online for days now and I can't find anyone who has this same problem with the VB6 Winsock. So here's my problem, I have a server with two winsocks in an array. I then have two clients each with one winsock control. Now the I have it set up is that the server first sends data to client A. Then client A receives that data and sends its own data back to the server. Then the server sends data to client B, once client B receives the data, it sends its own data back to the server. So data is being sent from a client to the server, then from the server to another client, then back to the server, and then on to another client. I did it this way because when I tried doing it the way I really want it to work, I was having problems. So I had to set it up this way in order to ensure that only one client is sending data to the server at any one time. This process works perfectly, however I want it to work in a different way, since as you can image, the more clients there are, the longer the delay in data transfer between each client and the server.
So what I really want to do, which I can't get to work, is have the clients send and receive data to the server whenever they want. That is, client A sends data to the server, and then the server sends data back, all while client B is doing the same thing. When I do this, even though I have a winsock array on the server, I run into a problem. When client A first connects, it begins sending and receiving data to the server. But once client B connects to the server, all communication between client A and the server stops, and only client B sends and receives data to the server. Now I've done some tests and client A remains connected to the server the whole time. But for some reason, it seems that if two clients send data to the server simultaneously, only one data arrival event fires, even though each winsock is on a different port. I have not installed VB6 SP6 yet, as I'm not sure this will fix the problem.
So I really do hope someone will read this and explain to me what it is that I'm not understanding or what it is that I'm doing wrong.
If you search for Microsoft KB articles on the Winsock control you will find a long history of flaws and bug fixes. There is absolutely no reason not to install SP6 before even attempting to use VB6, since a vast number of issues were resolved over time.
Once you've done that (and only then) is it really worth talking about problems of the sort you describe. At least it eliminates a significant number of known problems, and then it might be worth discussing your code.
Are you using none blocking sockets? I guess you should.
You should probably create a thread for each incoming connection.
So the main loop should act none blocking and create a thread for each incoming connection, that receives the data and sends the answer.
Related
I’m bulilding a web app that requires communication between clients. For this I’m using socket.io. Some data however has to be updated regularly in the database.
Some of them not that often (preferences, on button click) others in every second for example a timer value. This can not be calculated because the timer can be paused.
Right now whenever a client emits an event, it also makes a request to the backend to updated the database. I was wondering if it would be a good idea to have the socket.io server update the database so the clients would only have to take care of the socket communication? It seems to me that having the browser do a request to the backend is a bit resource heavy and takes out a bit from the advantages of the socket based communication
Edit: the back end of the app and the socket server are two different servers but physically they are on the same machine so their communication could be faster
the main point of using socket.io is that it allows you to push data to clients and clients do not need to check your server constantly to get the last changes, and providing a low-overhead communication channel between the server and the client.
you can call an API and also emit data and many other things on user click in your application.
it is a good idea to have the socket.io server update the database and you can also authorize each socket, save client sockets information and ...
Sorry for trivial question but I'm planning to create server application, but first I need to write down all possible (outline)
server scenario; I'm puzzled with one question of how server informs or gets state of client and notify it to other already connected to this server, clients.
PS After authorization we already be aware of client's state but what of further state of client,
How server knows about this, I think it's server's initiative to do that if yes HOW?
Generally, it's the client that should inform the server when something changes, otherwise you're wasting traffic by constantly polling the clients even when nothing has changed.
But this depends on what it is you're doing. For real-time scenarios, for example with a multiplayer game, the clients could constantly send their state several times per second even if nothing has changed. Likewise, the server would send the current state to all clients regardless of whether there were any changes or not.
I've developed a web-based application in which a signed in user should send a message to the server telling he is still online every 3 seconds. The message is then processed by the server and a stored procedure is called in Mysql to set the user's status to online.
I've looked in to similar issues in which Comet and Ajax are compared (here or here) but considering that 3 second delay is acceptable and maximum users of 1000 are online in the system, is using Ajax a wise choice or Comet should be used?
For this kind of feature comet is more appropriate:
Your clients send messages (i'm online)
Your server broadcast the processed message (user X is still online)
In an ajax way you are only serving messages to server.
In order to get the "broadcast effect" in an ajax way. You will end up doing something similar to comet but with less efficient bandwidth.
Ajax:
Client send server - i'm in
Server process
Server send back to client list of user in.
In this case every client ask every 3 second the database for the COMPLETE "in" list.
In comet:
Client X send server - i'm in
Server process
Server send back to client S that user X is still online
In this case every client tell the server every 3 second that he is in.
The server send back to every connected client ONLY that x is still in
Comet is just the technique to broadcast back and push messages to client
Ajax is the technique to push client information to the server without having to refresh all the page.
Quoting wikipedia:
http://en.wikipedia.org/wiki/Comet_%28programming%29
Comet is known by several other names, including Ajax Push, Reverse Ajax , Two-way-web, HTTP Streaming,and HTTP server push among others.
So go comet :)
If you do not broadcast anything, then simple Ajax is the best option
In this particular case, since you do not need to send any information from the server to the client(s), I believe Ajax is the more appropriate solution. Every three seconds, the client tells the server it is connected, the database is updated, and you're done.
It could certainly be done using Comet, in which case you would basically ping each registered client to see if it is still connected. But, you would still need to run a query on the database for each client that responds, plus you would still need the client to notify the server on its initial connection. So, it seems to me that Comet would be more trouble than it's worth. The only thing that might make sense is if you could ping each registered client and store the responses in memory, then once all clients have been pinged you can run one single query to update all of their statuses. This would give you the added bonus of knowing as soon as a client disconnects as opposed to waiting for a timeout. Unfortunately, that is beyond the scope of my expertise with Comet so, at this point, I can't help to actually implement it.
I have an EventMachine server sending TCP data down to a Mac client (via GCDAsyncSocket). It always works flawlessly for a while, but inevitably the server suddenly stops sending data on a connection-by-connection basis. The connection is still maintained, and the server still receives data from the client, but it doesn't go the other way.
When this happens, I've discovered via connection#get_outbound_data_size that the connection send buffer is filling up infinitely (via #send_data) and not being sent to the client.
Are there specific (and hopefully fixable) reasons why this might occur? The reactor keeps humming along, and other active connections to the server continue working fine (though they sometimes fall into buffer hell as well).
I see one reason at least: when the remote client no longer read data from its side of the TCP connection (with a recv() call or whatever).
Then, the scenario is: the receiving TCP buffer on the client side becomes full. And the OS can no longer accepts TCP pacquets from its peer, since it cannot store them queue them. As a consequence, the sending TCP buffer on the server side becomes full too as your application continue to send paquets on the socket! Soon your server is no longer able to write into the socket since the send() system call will :
blocks undefinitively. (waiting for buffer to empty enough for the new paquet)
ot returns with an EWOULDBLOCK error. (if you configured your socket as a non-blocking one)
I usually met that kind of use case in TEST environment when I put a breakpoint in my code on the client side.
There was a patch was applied to GCDAsyncSocket on March 23 that prevents the reads from stopping. Did this patch solve your problem?
Is this chat using "long polling" or "http streaming" ?
http://go-mono.com/moonlight/chat.aspx
It's not anything that simple. It uses http://www.mibbit.com/chat, which is a full IRC client written in Javascript and Java. Blog at http://blog.mibbit.com/.
Edit: Here's your answer.
The first part I got working was the communications between browser and server. That’s done using 2 XMLHttpRequests. The first one is simply to send data from browser to server. It utilizes keep-alive, to minimise new connections.
The second XHR is the ‘receive lazy polling’ one. It connects to the server, and the server holds it open until there are messages available, or a timeout expires. This one is also keep-alive, so the next request goes down the same connection.
What you end up with is 2 connections held open to the server, with packets (json in this case), and some http headers from time to time.
To make sure the server would scale, I wrote a custom webserver in java using nio. It handles all of the connections in a single thread and as I say, scales to tens of thousands of connections.
If the client requests a new connection, it sends a request to the webserver, which then connects out, and starts proxying etc. It also runs an ident server in the case of irc connections so that an irc server can identify individual browsers. I looked at existing frameworks etc to do this sort of thing, but I valued learning how it all works, and thought that my use case may be specific enough to be able to optimise more than general frameworks can.