I want to setup a datastreaming server in Processing, so the Client sends a String to the Server and the Server answeres it. For example Client - Server "Cupcake" then Server - Client "Cupcakce sounds funny" so the Server answeres the string. I tried this with the UDP library and opened the port on the server. But when the server had to answer the Clinet it did'nt work, because I can't open the client's ports. Any solutions?
Sounds like you need two-way communication.
Using UDP you would need two sketches that are both UDP servers and clients.
e.g.
sketch #1 listens on port 12000
sketch #1 sends data on port 12001
sketch #2 listens on port 12001
sketch #2 sends data on port 12000
You can also use TCP sockets.
As the Server you can use Examples > Libraries > Network > ChatServer
I'm surprised there's no ChatClient example, but you can get away with something like this:
import javax.swing.*;
import processing.net.*;
int port = 10002;
Client myClient;
void setup()
{
size(400, 400);
textFont(createFont("SanSerif", 16));
myClient = new Client(this, "localhost", port); // Starts a client on port 10002
background(0);
}
void draw()
{
background(0);
text("client - press ENTER to type\nconnected:"+myClient.active(), 15, 45);
}
void keyReleased() {
if (keyCode == ENTER) {
String message = JOptionPane.showInputDialog(null, "message: ", "TCP Client messaging", JOptionPane.QUESTION_MESSAGE);
println(message);
if (myClient.active() && message != null) {
myClient.write(message);
}
}
}
Note: The server must be running before the client so the client can connect.
Be sure to checkout the difference between UDP and TCP protocols to work out which one makes most sense to use in your case (especially if you pan to use more clients).
Another option worth looking into is WebSockets. This would allow you to have a WebSocket server in Processing and the client could either be another Processing sketch or simply any browser with WebSocket support(e.g. most modern)
Related
We have a situation where client writes faster than the server can read, say every 1 second or less a client writes to a server making the tcp socket buffer full and therefore disconnects.
How to handle this sort of situation?
Is there a way to check tcp socket buffer from client side before writing and waits until buffer is freed and can send again?
Here is a sample pseudo code to easily reproduce the issue
Server
socket = create server Socket at port 7777;
socket->Accept(); //wait for just 1 connection
while(true)
{
// just do nothing and let the client fill the buffe
}
Client
socket = connect to localhost 7777
while(true)
{
socket->write("hello from test");
}
this will loop until write buffer is full, and it will hang up, and will disconnects with win socket error 10057.
I have this binding socket:
Socket mainSocket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.IP);
mainSocket.Bind(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 0));
And I need to know when an extern client is connected and disconnected from my servicies( ftp, database server, app server, etc).
thank for advance.
What I have tried:
I tried with these methods but, did not work for me.
mainSocket.BeginConnect(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 0), new AsyncCallback(ClientConnected), null);
mainSocket.BeginDisconnect(true, new AsyncCallback(ClientDisconnected), null);
private void ClientDisconnected(IAsyncResult ar)
{
// here get some client info like Ip
}
private void ClientConnected(IAsyncResult ar)
{
// here get some client info like Ip
}
I need some help please. Thanks.
BeginConnect() and BeginDisconnect() are asynchronous operations. They are not events you can subscribe to.
BeginConnect() is for a client socket to asynchronously open a new connection to a server. BeginDisconnect() asynchronously closes an open socket.
To detect clients connecting to your server, you need to use Accept(), BeginAccept()/EndAccept(), or AcceptAsync() to accept inbound connections coming into your server socket. You will be given a new Socket for each accepted client to use for communicating with them.
There is no event for a client disconnecting from a server. If a client disconnects, pending/subsequent send/receive operations involving that client will fail. You need to handle those failures when they occur. For instance, if a client disconnects gracefully, a read operation from the client will end as successful with 0 bytes reported. But if the client disconnects abnormally, a read operation will end as failed with an error code reported.
I am developing a peer to peer call. I am using de.javawi.jstun.test .
I found this constructor in de.javawi.jstun.test.DiscoveryTest .
public DiscoveryTest(InetAddress sourceIaddress, int sourcePort, String stunServer, int stunServerPort) {
this.sourceIaddress = sourceIaddress;
this.sourcePort = sourcePort;
this.stunServer = stunServer;
this.stunServerPort = stunServerPort;
}
My question is What is the difference between the Source Port and the StunServerPort??
stunServerPort is the port the STUN server listens on for incoming binding requests. This is typically one of the standard STUN ports: 3478 or 3479.
sourcePort is the port the client behind a NAT has obtained locally to create a socket with. Most often, the client attempting to do P2P will ask the OS to randomly pick an available local port to send/receive from. You can probably pass 0 for sourcePort and let it pick the port for you as well. Or if you already have a socket, use the same port as your local, and DiscoveryTest will set the reuseaddr flag so it can have a socket co-exist.
I am developing an application in which i am using socket for the communication between server application and client application(web and desktop both). My server application continuously listening the request of the client application and accept the request whenever comes.
Server code :
TcpListener listener = new TcpListener(IPAddress.Parse(ipAddStr), portNum);
listener.Start();
while (listen)
{
TcpClient handler = listener.AcceptTcpClient();
// doing some stuff
// for every client handler i am creating a new thread and start listening for the next request
}
and for web client i am using WebSocket, as for establishing the connection with WebSocket client we have to follow some handshaking process. and for that I am using the following code (which is working fine) :
static private string guid = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
private static string AcceptKey(ref string key)
{
string longKey = key + guid;
SHA1 sha1 = SHA1CryptoServiceProvider.Create();
byte[] hashBytes = sha1.ComputeHash(System.Text.Encoding.ASCII.GetBytes(longKey));
return Convert.ToBase64String(hashBytes);
}
generating and sending response for handshaking with websocket client:
// generate accept key fromm client header request
var key = headerRequest.Replace("ey:", "`")
.Split('`')[1]
.Replace("\r", "").Split('\n')[0]
.Trim();
var responseKey = AcceptKey(ref key);
//create the response for the webclient
var newLine = "\r\n";
var response = "HTTP/1.1 101 Switching Protocols" + newLine
+ "Upgrade: websocket" + newLine
+ "Connection: Upgrade" + newLine
+ "Sec-WebSocket-Accept: " + responseKey + newLine + newLine;
//send respose to the webclient
Byte[] sendBytes = Encoding.ASCII.GetBytes(response);
networkStream.Write(sendBytes, 0, sendBytes.Length);
networkStream.Flush();
I have also TcpClient socket used for desktop application, so the problem is how to identify that the request is from WebSocket or from TcpClient ?
The easiest way would be to have a websocket listener and the vanilla TCP listener listen to different port numbers. You should do that anyway, because it is customary for websocket applications to run on the standard http port 80 (or standard https port 443 when you use websockets with TLS), while a custom protocol based on TCP should run on one of the ports from the "registered" range between 1024 to 49151. You are well-advised to follow this, because a well-secured client environment which allows web access but not much else might not allow the user to connect to other ports than 80 and 443, while any non-http traffic on these ports might trigger an intrusion detection system.
When you still want to handle both protocols on the same port for some reason, it will be a bit difficult. Websocket is a protocol based on TCP which looks like a vanilla HTTP GET request at first, until you receive the headers Connection: Upgrade and Upgrade: websocket.
That means connection requests for either protocol need to be accepted by the same listener at first. Only after the client sent enough data to identify its connection attempt as either your custom protocol or websocket (or something completely different which accidentally connected to your port - you will encounter that a lot when you deploy your application facing the internet) and then delegate the communication with the client to the appropriate handler class.
A TcpClient is a Socket wrapper.
WebSocket is a protocol that can run over a TcpClient. WebSocket protocol defines the handshake and how to frame data.
The best way of differentiate simple TCP connections and WebSocket connections is to have them listening in different ports, since you are going to use different protocols. It would be bad if you have them in the same port, it will become a mess.
I have a simple Python server which can handle multiple clients:
import select
import socket
import sys
host = ''
port = 50000
backlog = 5
size = 1024
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((host,port))
server.listen(backlog)
input = [server,sys.stdin]
running = 1
while running:
inputready,outputready,exceptready = select.select(input,[],[])
for s in inputready:
if s == server:
# handle the server socket
client, address = server.accept()
input.append(client)
elif s == sys.stdin:
# handle standard input
junk = sys.stdin.readline()
running = 0
else:
# handle all other sockets
data = s.recv(size)
if data:
s.send(data)
else:
s.close()
input.remove(s)
server.close()
One client connects to it and they can communicate. I have a third box from where I am sending a RST signal to the server (using Scapy). The TCP state diagram does not say if an endpoint is supposed to try to recover a connection when it sees a RESET. Is there any way I can force the server to recover the connection? (I want it to send back a SYN so that it gets connected to the third client)
Your question doesn't make much sense. TCP just doesn't work like that.
Re "The TCP state diagram does not say if an endpoint is supposed to try to recover a connection when it sees a RESET": RFC 793 #3.4 explicitly says "If the receiver was in any other state [than LISTEN or SYN-RECEIVED], it aborts the connection and advises the user and goes to the CLOSED state.".
An RST won't disturb a connection unless it arrives over that connection. I guess you could plausibly forge one, but you would have to know the current TCP sequence number, and you can't get that from within either of the peers, let alone a third host.
If you succeeded somehow, the connection would then be dead, finished, kaput. Can't see the point of that either.
I can't attach any meaning to your requirement for the server to send a SYN to the third host, in response to an RST from the third host, that has been made to appear as though it came from the second host. TCP just doesn't work anything like this either.
If you want the server to connect to the third host it will just have to call connect() like everybody else. In which case it becomes a client, of course.